With the advent of the Single Stack AEX system from PI 7.1 onwards, the configuration of interfaces has shifted to creating one single Integrated Configuration (ICo) with all the message processing steps included under one roof.
While this has simplified the configuration part of Process Orchestration, no longer creating separate objects for Sender Agreement, Receiver Determination etc., we realized that this introduced a completely new challenge when migrating a one-to-many scenario from dual to single stack.
The scenarios in question included sending Point-of-Sales data like prices, promotions etc. to stores. In the classical config, this would have meant creating separate Receiver Agreements for each of the Receiver Business Systems\Components and adding the receivers in the single Receiver Determination object. In the ICo approach, this meant adding all the Receivers to the same ICo, which meant creating one single bulky ICo having 1000+ receivers. Opening the ICo or any of the associated objects (communication channels) for reading or editing becomes a challenge in terms of time taken. Not something you would want from a support perspective.
Since the receiver FTP adapter does not support dynamic server address, we had to go for a custom solution to get around this problem. The solution used was to go for a custom adapter module to support dynamic server address. Each receiver is identified by a unique key which is used to store the FTP server details (server IP, user, password, filename, path, encoding) in a database table. The ICo has a single common receiver with a receiver file channel where the module is called.
In the message mapping, the unique receiver key is populated in the one of the unused Adapter specific message attributes as this information was not part of the receiver payload. If the receiver payload contains this information, this step can be omitted. In the adapter module, this key is retrieved from the ASMA (Adapter Specific Message Attribute) and used to lookup in the database table to retrieve the FTP details.
The code then opens an FTP connection to the intended server and writes the file in the path retrieved from DB lookup before closing the connection. The module then returns an empty payload to the next message processing step CallAdapter. This is important as in the receiver channel, the option “Ignore empty payload” is set. This ensures the successful completion of the message processing step during runtime.
Few things to keep in mind when developing the solution.
- In case you need to write a text file, you can use the MessageTransform Bean before the custom adapter module in the modules tab.
- For FTP, you can either go for open source or any of the other FTP API’s available. In our case, we found an issue with the Open source Apache FTP API with hanging threads, hence went for a third party provided FTP API.
- It is very important to provide as much details in the logs as possible, like receiver key, FTP details, filename etc. Since all messages are routed to the same receiver, we need to rely on the adapter module logs for support purpose.
- The receivers can be segregated per region or based on any other such property. In this case, the ICO will contain a separate receiver business component per receiver group. The advantage here is in terms of separating messages when we are looking for the files sent to a particular receiver, as we only need to drill down the messages for that receiver group.
- Instead of an adapter module, a custom adapter can also be built as that would provide a little more flexibility in terms of boundaries.
- For the common receiver channel, any adapter type can be used instead of the file channel. The important thing to bear in mind is how the message processing needs to be completed since the actual writing of the file happens from within the module.
- In case you want to avoid performing a DB lookup from inside the module, this can be done in message mapping step and the information stored in the ASMA properties for retrieving in the module.