I have not been a fan of the scenarios created in XI and PI. I have mostly used the scenarios to document objects, which already had been implemented. By adopting this process the scenarios was often lacking functionality or missing important objects. The scenarios served mostly as a form of documentation, for PI developers with less knowledge of the interfaces designed.
My main reason for not using the scenarios was the following.
- They could only be used to configure some objects in the auto configuration phase. It was not possible to generate a sender agreement, which then had to be created manually.
- When new scenarios had to be configured, partners and systems should be selected. For configuring just a few objects.
- The scenario cannot configure all necessary objects to be used. It is something like “Exactly Once In Order” sequence and routing rules.
With the above reasons it was I was not very excited about using scenarios in PI projects. Fortunately my colleague Emil Jessen, had a lot of ideas on why to use scenarios. The primary reason was to use them as a dialog tool to communicate integration processes with the business teams. The other reason was to use them for auto configuration of objects.
The scenarios should also make the hand over to the customers own people easier. They should be able configure the test and production environment and thereby have ownership of the solution. They did unfortunately not have the time for the configuration part, so we could not see how it worked.
The main focus was on creating a way to communicate, how we pictured each process and the messages flow in the process. The swimlane diagram is easy to understand since it deals with interaction between systems. It also described how the flow was when using BPM’s.
The use of models is going to get much more used in PI 7.1. I have tried to use the functionality as described in this blog. In PI 7.1 the models can get more complex and be used to describe how the business works. I’m looking forward to see if the models in PI 7.1 can give a better understanding of what is going on or they are too complex for the application consultants.
To streamline our use of scenarios the following guidelines was created.
- The scenario should describe a process and the scenarios should be named after the process.
- Scenarios was created in the beginning of the realization phase and populated with dummy actions until it had been defined each action.
- Actions should be marked as with start and end action(s).
- Actions used in a scenario should contain a description. This description should contain information on what the action is doing. It could be send message, provide lookup service, consume lookup service and send message. And then a more detailed description on what the interface did.
- In descriptions for actions and scenarios the technical specification number was added, it was therefore a lot easier to find a scenario by using the search functionality.
- Actions can have multiply interfaces, which could be used in different scenarios and in different ways. As long as the different message does the same it could be an IDOC and an BAPI, which both creates an invoice.
- Communication channels temples should be places on all communication channels, which needed a sender agreement.
- All configurations of scenarios should be done by using the scenarios, except where the limitations are as described below. This mean that it is easy to reconfigure all interfaces in a PI system, simply delete all configuration objects, except communication channels and then auto configure everything.
A scenario could look like the following. Emil had also taken the time to translate the actions to English.
It is easy to get the auto configuration for work for sender agreement, but was not documented where I looked. The solution is simple. Just place a Communication Channel Template on the sender side in the Connection between actions like showed below. It is then possible to select a communication channel in the configuration. Venkat Donela had a blog where he describes how to use the communication channel temple, I was just pointed to this blog recently.
We still need a way on how do document, which changes there need to be implemented after the configuration has been performed. This could be creating Routing determinations and the sequence for interface with EOIO. We have currently documented them in our cut-over plan, so we know what to do when we go live. Have anybody solved this problem.
I got a comment about the diagrams from one of the application consultants. He thought the diagrams were a nice way to represent what did happen in the interface. For them it looked like the solution maps, which they where use to see. It was nice to know that the diagrams could be used by the business experts to show what we were doing and we are on the right track in with the development.