Migration to SAP PI

Disclaimer: These are all my own views only, and do not represent that of my employer's or anybody else's

I am fortunate enough to get to the vicinity of a couple of migration projects, where we had been replacing some other middleware(eg. eGate , Mercator) with SAP PI. During the process, I have learned that migration requirements pose a different set of challenges than implementation requirements. During implementations, our main focus remains on getting clarity on the requirement, which generally changes, and gets refined in some form or the other, till the point of go live and beyond, and then use the middleware tool's features to best design the interfaces. Thus, best design is driven by the tool's abilities and out of box features provided. Over that custom codes are written to supplement the gaps and fulfill the requirement.

However, when we are talking about migration, the requirement is already known and functional with a different middleware tool. The present design is based on the present available tool's capabilities and best practices. These capabilities and best practices will differ from tool to tool , so, what is best designed on one tool might not be the best design for PI, thus posing frequent challenges to the migrating tool's capability. Thus an as is migration might not be the best possible way to choose, and in most cases might not be possible altogether. These technical challenges will lead to greater complexities, and might lead to a very clumsy situation unless dealt with properly from the very beginning of the project.

Thus approaching a migration project turns out to be a vital parameter for the success of the project. Below are some of the factors which should be taken into account from the Blue Printing phase.:

1.  It is important that a comparative study between the tools is handy.

2.  Study the present requirement and try to classify them (based on the visible PI design). examples might be "Control M" - Signifying interfaces which works along with the scheduler Control M; another example may be "External Web services" , denoting interfaces interacting with external Web services. Below are the few patterns /"pointers to define patterns" that I can think about now:

• Synchronous / Asynchronous
• Interfaces working along with other scheduling tools.
• EDI Interfaces
• Stateful Requirements / potential ccBPM requirements
• Special Scheduling requirement
• Dependency requirements
• High Volume interfaces
• High Frequency 
• Real time requirement
• Protocol support required which are not provided by PI standard adapters
• Special security requirements, eg: involves digital certificate / sFTP requirements etc.
• Publish-Subscribe pattern
• Business Critical Interfaces
• Any requirement for High availability for specific set of interfaces
• Any other patterns specific to the requirement
• Third Party systems -- in most cases 3rd party systems pose unique(specific to the 3rd party) interface challenges

Next, carry out a high level design and feasibility study of each pattern. Incase adequate time is provided , a deeper look at the individual interfaces is worth. Try to narrow down the classifications into PI design patterns.

In the process, certain limitations of the tool is expected to crop up. There are chances that these limitation will have a certain common solution and should be studied carefully for something which is generic / at least can apply to a group of interfaces as generic-parameterizable solution. This solution might range from --a design pattern, writing custom Java or ABAP Maps/ proxies / Adapter Modules / operating system scripts , creating a map convertor etc. A cost analysis needs to be carried out to gauge the advantages / disadvantages of building the generic solutions - it is more likely that certain generic solutions will pass and will be applicable for a significant mass of the interfaces.

At this point of time, we should have some generic solutions available and some specific problems to be addressed which looks to be much simpler and less clumsy to be dealt with than where we started from. A lengthy Blue print/ requirement analysis / design phase is worth invested!!

PI 7.3 - Adapter User-Defined Message Search

As all of us know one of the interesting feature enabled with PI 7.1 EHP1 dealt with User-Defined Message Search. But since (as mentioned in Note 1247043) PI monitors in NetWeaver Administrator (NWAPI) is not supported for production scenarios most of us could not use this feature any further. With PI 7.1 EHP1 Support Package 6 the user defined search could only be configured in & used for the integration server ABAP client. As all of must be aware of by now the PI 7.3 comes with a JAVA only installation option (AEX). So does this mean we cannot use user defined message serach with AEX. Well the good news is now the user defined message search can be configured and monitored from an AEX installation. The user defined message search has been integrated with the new configuration and monitoring tool (pimon).

In this blog I will show how to configure and monitor user defined message search for an AEX installation (PI Adapter User-Defined Message Search). This holds true for a dual stack installation as well.

Configuration:

Navigate to PI Adapter User-Defined Message Search either via pimon->Configuration and Administration from the directory start page or via NWA -> SOA ->Monitoring -> PI Adapter User-Defined Message Search Configuration

Now click on the new button to create a filter and Provide the values for required fields along with sender and receiver components as shown below. All the values will be available via drop down (search help).

Now we need to create the search criteria for this filter (in the details section). This means we need to enter the fields we want to monitor on a given payload. You can monitor more than one field of a payload at once, only thing you need to create separate search criteria for them. You have an option of either monitoring a payload value (XPATH expression) or a field from the SOAP dynamic header. Please note the XPATH expression must yield a single value.

I am using the following test payload for this blog

Now we need to provide the namespace for the prefix value we have used in our XPATH expression. The only restriction is the prefix value cannot be longer than 8 characters.

Now if needed we can test our filter configuration by using the Test Search Criteria button.

Monitoring:

Now we can process a message which satisfies the filter criteria and navigate to the Message Monitoring section to check for the payload and the filter. In the Message Monitoring->Database we can use the user defined search criteria under Advanced option to provide our filter and corresponding values. Here you can provide more than one search criteria for a payload search which you have defined in the configuration step earlier.

You should see all the message that satisfy the filter condition.

Note: Now you can see a new tab has been added to the messages that satisfy a given filter with the set attribute and their corresponding values as shown below.

The user-defined search is one of the many ways to find messages in the Advanced Adapter Engine using the message monitor without the use of TREX. Optionally the user-defined search is also available for searching messages in the Integration Engine. You can configure it using transaction SXMS_LMS_CONF in a dual stack installation as well.