Can SAP PI and Seeburger Business Integration Server (BIS) co-exist in an Integration landscape?
SEEBURGER Business Intelligence server (BIS) is one of the most common EDI translators in most SAP Implementation projects. SAP PI is also typically available in such a landscape being extensively to support various Integration needs.
SEEBURGER BIS has distinct features to support B2B communication/Integration. A few of them are as follows
- Managed File Transfer
- Out of the Box/Standardized EDI translation mechanisms
- Support for secured protocols like AS2, SFTP required for critical and sensitive financial/Customer transactions.
- Support for High Volume transactions and large message sizes.
- Out of the box features for Partner/Agreement management.
With that said, BIS has certain limitations in its native integration with SAP systems. The integration mechanisms available are IDOC and File systems. SAP PI can bridge the gap to produce an efficient implementation.
The following are a few use cases for SAP PI and SEEBURGER BIS to be used together in a landscape
Native communication with SAP systems
In majority of SAP implementations, a common integration strategy used is to avoid creation of custom IDOC types. More so in cases where the number of source fields on the interface is not large and custom logic needs to be implemented to populate such fields. ABAP Proxy using the XI adapter is an obvious choice in most cases.
SEEBURGER BIS does not support a proxy like communication. In order to achieve the same a pass-through or a hop interface can be built with SAP PI passing the message to SEEBURGER BIS, without any data transformation. BIS can then transform this message into an acceptable target format and transmit it to the business partner via a secure channel.
BIS supports inbound and outbound HTTP calls. SAP PI can connect to SEEBURGER BIS via a receiver HTTP adapter.
This would reduce the development effort of an SAP system by avoiding creation of custom IDOC types. This should only be done for interfaces in which the message sizes are not too large and the additional delay in message processing due to the hop interface is acceptable. This would avoid failures in PI due to message sizes.
Transmission of data to business partners using secured protocols like AS2 or SFTP
This is a case in which, message sizes are small and the transformations are easily achievable within SAP PI or is delivered as predefined content within SAP PI e.g. SAP ECC and Experian Integration for Credit Checks. Here the requirement is to deliver files (non-EDI) to business partners using secured mechanisms like SFTP or with encryptions not supported out of the box in SAP PI.
BIS supports an out of the box FTP server. This server has 2 nodes a Central or Internal Node and an external node on the DMZ. SAP PI can generate a file onto the central BIS node. BIS can then deliver the file via secured mechanisms like SFTP to business partners.
This is a pass-through process in BIS.
These are a few patterns which I implemented in one of my implementation and was able to achieve reduced development times and additional security benefits.. The PI version used was SAP PI 7.11 and the SEEBURGER version used was SEEBURGER BIS 6.3.3
I have led the implementation of a Business Integration Server (BIS 6.3.4) as EDI Gateway combined with SAP PI (7.11) as A2A integration platform.
The points you mention are valid. Once you go towards large scale partner connection rollouts however you begin to see that the standard process (S-11000) delivered by Seeburger requires the creation and transport of a lot of objects; it's because BIS expects to be connected to backend systems rather than another middleware.
For this it becomes handy to be able to rewrite the process definition to offer a more dynamic approach for routing, especially if you use BIS mostly for its (de)XMLizing capability and technical connection protocols. That's a serious investment, but it's going to repay itself when you plan to move hundreds of partner connection.
When thinking about Seeburger and PI, there is also always the chance to bring BIS functionality into PI by using the EDI adapters Seeburger offers for PI.
Looking back over 5 years of project work in the Seeburger and SAP integration world, that's what I would advise customers to do:
1. If possible, use one platform only and add functionality you need by buying additional adapters.
2. If using BIS and PI in the same landscape, make sure you chose a sound architecture and be willing to adjust the standard processing on both machines to make them fit better than they are out of the box.
Stefan
I was looking for some strong reason to use have both in the landscape, however I couldn't find one (considering a new implementation). One case would be when a customer has invested in BIS and would like a more strategic integration solution in landscape. With PI already in landscape, implementing entire BIS appears to be an overkill.
Best regards,
Prateek Raj Srivastava
I was involved in a fresh implementation: A SAP PI 7.11 system was implemented to handle A2A integration and a Seeburger BIS 6.3.4 was implemented to handle B2B integration.
The choice was based on the architectural principle that you want to divide the task of content conversion (A2A - PI) and content delivery (B2B - BIS).
A basis for that decision was that there are simply more graphical mapping developers available on the market than business integration converter developers. Besides, BIS is a java only tool that is able to handle larger items than PI 7.11 - think large file transfers (up to 4GB).
The problem with that pattern is that it is not always clear cut if an interface is A2A or B2B - and you do not want to run every item through both PI and BIS - again think of large files that need to go from an internal system to an external system.
Looking back, I would advise for a new implementation to take the one or the other system.
I think your blog strikes for mergers where a BIS and a PI system get together into a combined system landscape, both holding end to end integration scenarios. Then it indeed becomes a good decision what to do and what to keep. After all both systems cost money to run and maintain.
A nice challenge... 🙂
Nice challenge for an Architect and a Consultant, failing in which could cause real nightmare to the implementation team. 🙂
And, about the java only BIS you mentioned, PI 7.3 Java only is already in. 😉
Thanks for sharing this experience!
@Abhishek
Have you encountered some customers with such landscape. Did you have chance to analyze the landscape and understand the strengths and weaknesses of such landscape. It would be nice to see such points in the blog.
I had been a part of a complex implementation in which both BIS and PI were in the same landscape. A thorough analysis was done before taking a decision on having both the solutions in the same environment.
The Driving factors were
1. Sheer High volume ( over a million transactions to customers.Vendors and Banks ) of transactions
2. High messgae/File sizes upto 200 MegaByptes
3. Requirement of a dedicated DMZ FTP server.
4. Requirement of secured (using protocols like SFTP ) protocols and Managed File transfer.
We did a an extensive hardware cost analysis to compare between PI only, PI with Seeburger EDI adapter and Seeburger BIS. We found that both PI and Seeburger EDI adapter would have created the same load on the PI server and would have resulted in higher costs for hardware and maintaniance.
The combination of PI and BIS for hop interfaces should be limited to specific scenarios which do not create additional cost for PI
Abhishek
Do you have any recommendation about which type of interfaces was preferred with
- only PI
- only BIS
- both PI and BIS?
Regards,
Prateek Raj Srivastava
Unfortunately the cost analysis is confidential to the client. It depends on specific vendor agreements with the client.
The Following is the recommended path ( per the implementation)
PI only - for all A2A communications, with 3rd party/Legacy systems. The message sizes to be optimized and not exceed 20 Megabytes. This can include all kinds of communication types like JDBC, SOAP, JMS etc.
BIS only - All B2B communications to Vendors/Customers/Banks should go through BIS. These contain message sizes ranging from 200 Megabytes up to 20 GB. For a development perspective standard Idocs/basic extensions are used on the SAP system. Along with this there are additional security requirements like using encryptions, SFTP and AS2.
PI and BIS - This should be used in case
1. Message sizes are within optimized limits of 5MB to 20 MB.
2. Additional security requirements like usage of AS2/SFTP protocols.
3. Number of source fields are less and no standard Idocs exist for such scenarios.
4. Pre-defined mapping exists within PI e.g. Experian (Credit Agencies ) integration with ECC with an additional security requirements.
5. MFT requirements for 3rd party service providers or systems.
Regards,
Abhishek