Ever came across a situation where you were trying to find out a particular configured scenario in PI Integration Directory and confused between couple of similar ones. Or searching for a Communication Channel and found that there are many channels with almost similar names with all their agreements in place. This usually happens when we are managing a real large PI implementation landscape and unfortunately (or fortunately) we have not implemented it yourself.
The idea of this wiki is to emphasize upon the significance of having a clean Integration Directory. If the current landscape is very small but there exist possibilities of adding new scenarios, make sure to keep things clean right from start or otherwise it would be a complete mess in future.
What all could be the reason for such a mess?
1. We know that this new method would show much better performance. But let's keep these old ones too for a Backup solution.
Unfortunately - It remained in the same Configuration Scenario making room for confusion to all of those who will refer this in future.
2. Transports of individual objects are done from Quality system to Production.
Unfortunately - The simple option of "Add to Scenario" was not used and the actual object was lost in the "Objects" tab instead of finding some place in "Scenarios" tab.
3. New protocols or standards are adopted due to which the overall integration landscape has become more standardized.
Unfortunately - The traditional ones are not removed.
4. We know this is our Production system, but sooner or later we need to test communication with other systems
Unfortunately - These objects stayed in the same Scenario where Production flows resided adding up to the mess.
5. For communication with similar partners different mappings and objects were used. One day someone suggested, "Why to use so many mappings, use multi-mappings".
Unfortunately - The redundant mapping remains as it is.
6. The name of business system/ service is not very appropriate, let's change it to some logical name.
Unfortunately - Many objects with old Business system name were not deleted.
7. Company A has implemented the scenario with Method A. Company B took over and implemented Method B for better performance
Unfortunately - then haven't removed Method A configurations
There could be many other reasons for this mess which could you included by the reader
Let's take an example when we have to say, "Oh! What a Mess!"
Suppose we have some conditions in Interface Determination based on which different mappings are done from same source structure. Customer one day complains about the data sent in incorrect format and to solve this on high priority. We would start searching the message using our standard monitoring options, but finally would end up logging into Integration Directory for the actual processing sequence. And that was the point at which the horror begins. This horror could have many faces like
1. The channels used looks almost similar. If I have 30-40 agreements in each scenario, do I need to open them individually to find out which channel was using which scenario?
2. Do I need to search the "Objects" list now for the configuration that I couldn't find in "Scenarios"?
3. Time is ticking, how to make sure that I am looking into the correct scenario?
There could be many alternatives to react here to solve the issue. However, a better approach would be demonstrating Proactive behavior by cleaning the mess in the first place and thereby avoiding any such related problems. So now our attention should be turned towards the cleaning process. Although there are no defined steps for going about this cleaning, but we can atleast have a short checklist of easy steps to make sure we tried our best to keep it clean
Checklist of Keeping ID Clean
* For existing confusing objects, use PI monitoring options to see if you have received any message in Production since past few months for the set of Business System/ Services and Interfaces. If there are no messages, you can delete the objects.
* One Exception to above point comes when you have used some option in Receiver Determination like "If No Receiver is Found, Proceed as Follows". It is possible that the receiver specified in this case hasn't received any message since months. These cases have to be considered before actual Deletion of objects.
* If there is a Backup solution in Production landscape, separate it from the existing configuration either by adding it to a new Configuration Scenario or by adding a logical name to the objects involved.
* Above point also applies for the cases where you have test objects in Production for testing communications.
* If you mange some Interface specific document in your landscape with details of all the objects, then updating it should be a routine before delivering the object.
* Another point to be added in the routine should be adding the object to appropriate Configuration Scenario as soon as any Transports are performed. "Add to Scenario" is not that difficult option.
* Adding same object to multiple Configuration Scenario won't harm as far as its logical.
* Create an Improvement routine for your organization which should be different that the actual Development routine. One influential but simple point the Improvement routine should be removing the objects from ID as soon as the improvements are implemented.
* Adding appropriate Description to objects will always help. However, to see the description we have to open the objects. If we have say 50 such objects, then it would be better to perform the above steps first to rely upon the description.
Operation Management 
Systems 
.
