As a PI consultant, I face different situations that require different solutions. With PI AF, I have been involved in defining a corporate framework to allow development on the promising Analytic platform of the PI server.
At the moment, the strategy that was adopted was to have a self-contained database for each new project that needed a PI AF template-based platform. The main driver behind this was nothing else but the fact that we can create as many database in AF as we want and the fact that we can segregate these environments during development was also seen as a good thing (with many developers from various company on different project, we didn't want to face situation where someone would crash the system and impact other developers).
However, nothing is so simple in this world and I'm facing a new scenario that kind of opens my eyes on different alternative and issues regarding the corporate strategy we adopted in the early day. I'd like to probe the good people on vCampus for opinions and solutions.
Here's the new situation:
I need a new hierarchy of elements, with new templates to deliver a reporting infrastructure. However, some of the configured data that will be stored in AF are not expected to be PI point but rather using attributes of type Double. The trick is that we already have a calculation engine build in AF (using its own database and template completely segregated from the external world) and I'd like to be able to link the AF attributes of the new database in the attribute of the other (external) AF database. This would eliminate requirement for having to replicate multiple set of data in different DB. To achieve something like this, it seems obvious that I now need to review my initial concept of having segregated database.
However, we are also about to try a new product developed by a third party and this product expose hundreds of template. As a segregated environment, this database with the hundreds and hundreds of template would be self-contained and quite easy to maintain. Now the dilemma I face is as follow:
Should I have a single AF database for a whole corporation or should I stick to the segregated model. The following sections explain the pros and cons of each situation
All in a single instance of AF Database
- Finding proper template from the sea of template for a given configuration effort. AF Explorer allows you to filter your template library by Categories but when it comes to choose your template from the palette or the associated menu in the Elements section, no filtering is available.
- I had to rebuild my whole AF database from scratch a couple times during development because of weird bug like having an element not completely erased from the system, etc. (It was in AF2.0 if I recall, not sure if it happened in 2.1). What if I break 20 applications when trying to deploy/maintain a single one?
- When using AMI, how will I cope with potentially 1 million smart meters scattered in my AF database when all I want to do is add a single element in a simple AF structure used for some simple reporting application that actually share the space with the crucial AMI infrastructure. How about managing or adding the appropriate template to this hierarchy/calculation.
- Template reusability. I would be able to maximize integration by promoting maximum code/template reusability...but at what price in the future.
Every Application in a segregated AF Database
- To ensure user don't have to configure the same information in multiple databases, we need to enable some programmatic access to external AF database. For instance, if in DB_A, object 1 as an attribute A and I want to make it visible in DB_B through object 2 in its attribute B, I would need to allow connectivity to DB_B using the connect method of AF in .NET via some external application (ACE, Windows service, etc.). In a single DB model, this is trivial.
- Every template is segregated. This means that if an application is simple and has a small number of templates, it will be easy to manage.
- When developing, upgrading or managing an application, no impact to external and potentially other critical system is to be expected because of the segregation of configuration and database.
- I could still stick to the segregated model but when a requirement is identified to enable communication between different AF databases, I merge both structures together.
- This could potentially lead to a complete merge of every DB and end up being the all in a single instance of AF database option.
I just don't know what is the main trend regarding the recommended architecture and it potential ramification in the future. If you would be kind enough to share some of your thought on the subject, I'm sure the whole community would benefit from it. Maybe using Analysis Rules (allowing connection to remote AF DB) would be a scenario to evaluate in regards with the segregated model.