Posted on

Using PI scenarios

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.

Posted on

Modeling tools in PI 7.1

With PI 7.1 it is possible to create Aris Models within the Enterprise Service Builder. This will make it easier for the integration team to model the process and interfaces.It is possible to go from the high level business process models, all the way down to an interface implementation and configuration of integration scenarios. The use of models adds an extra layer of documentation of the business processes in conjunction with the Enterprise Services (ES). The models can be used to get an overview of how a scenario is created.

This paper will contain information about which models can be used in PI 7.1 and which meaning they will have for a PI developer.

The Sales Order model is based on the ES for sales orders. But the modeled system contains more information than it is possible to find on ES workplace. What is added to the models in the ESR is how the services can be connected in a specific scenario.

At first look at the models there are a lot of different models. It takes a little while to get used to the models, and figure out which models can be used for which purpose. There are 12 different model types, and all of them can be used for describing a business process in different ways and levels.

At the highest level different integration scenarios are grouped together. An example of this is the SAP Scenario Catalog, which is a grouping of different scenarios. This model makes it easier to understand how different scenarios belong together and to find the scenarios that have something in common.

An example of the scenario catalog is the following.

An Integration Scenario is a high level overview of what Deployment Units are used. In each Deployment Unit there is one or more Process Components which can contain a number of process steps. The connection between the Deployment Units can be linked to information about the integration scenarios.

The interaction between the Process Components can be described in a ProComp Interaction Model.

A ProComp Interaction model shows how different Process Components relate to each other, for instance the message flow between Process Components. An example of this is showed below.

The ProComp Interaction model can contain information about what Service Interfaces are used and the mappings they contain. This information can be used to configure an Integration Scenario by adding information about business systems and where the different process components are installed – and by selecting adapters. Then it works just the same way as an Integration Scenario in PI 7.0.

The ProComp model can also be used to describe how the flow is within a Process Component. This type of model seems to be more useful if the aim is to document how Enterprise Services are connected within a Process Component. An example of what the ProComp model could be used for: To describe what is going on in a BPM (Integration Process in PI) which can then later be created based on the model.

It is still possible to make use of integration scenarios from XI 3.0/PI 7.0. These scenarios do not explain the business in the same detail as some of the other model types. They do, however, provide information about which connections are used and how the messages are mapped. The integration scenarios are easier to understand for a PI developer since they give information about which connections are used in a direct fashion and because they have been used earlier versions of XI/PI.

It takes a little while to get used to working with the models in PI 7.1 and to create models which can be used and understood by developers and Business Process eXperts ( on SDN SAP has a BPX community).

The use of models does seem to create some extra overhead compared to a top-down approach which starts with an Integration Scenario and the objects are created to fit into the process. To be able to make such a scenario one would normally create a drawing to describe what is going on and to support development of the scenarios. This drawing is often a process diagram, for instance in Visio, PowerPoint or on paper. With help of the built-in model tools it is now possible to store such models within the ES Builder, thus serving the purpose of documenting the process and context to which the interface belongs.

I recommend to invest time in establishing naming conventions for modeling and guidelines for when and how modeling should be used.

A question which has to be answered is if models should be created for all integration scenarios – or only when Enterprise Services are involved? I probably need to use modeling in real projects and then evaluate if the use of modeling makes sense.