Skip to Content

SAP XI IN ACTION

Blog highlights the approach followed in the real time for integrating 3rd party file system with SAP IS-U using the SAP XI. It also throws light on the pro’s and con’s of the approach. This blog discusses the approach specific for file to idoc scenarios. In our current project we have around 80 different outbound file based interfaces, which has to be posted as Idocs into SAP IS-U system. We have to configure the 80 file adapters to poll the files, which will be a performance bottleneck. We as a team decided to go for a common approach, which can overcome the above bottleneck. We implemented it and found it really easy and useful. We also developed lot of generic objects, which benefited the project and the team. I will share them in the upcoming blogs.

Let me quickly depict the approach:

1.3rd Party file system sends files and those files are routed to a common folder.
2.Common file CC adapter will poll for CSV files belonging to any interface.
3.After files are received, common file adapter routes them to a common ccBPM.
4.Common ccBPM does content based routing to interface specific ccBPM using the file type in the payload of the file.
5.Interface specific ccBPM converts the common file structure into interface specific idoc structure.
6.Idoc adapter converts the incoming XML file into Idoc format and routes it to the receiver configured in the integration directory.

It can be depicted graphically as shown below:

Generic Approach

Pro’s:

1.Good Performance.

2.Re-usable integration directory and repository objects.

3.Cut down of development effort.

4.Approach itself can be re-used across any XI projects, which involve File-Idoc scenarios.

Con’s:

1.Having one file adapter might slow down the performance, as it is queue based messaged processing. Messages might be held up in case the file adapter is down. However, appropriate number of file adapters can be designed basing on the volume and frequency of file specific to XI project.

2.Initial efforts have to be done to make the proto-type work. Since already the initial efforts are done to make the prototype work, which I will be sharing in the upcoming blogs, the efforts for the upcoming projects are minimized.

Please wait for the upcoming blogs for granule details of the implementation!!!!!!!!!!!!

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Rekha Lather
    Nice approach to cut down no of interfaces.We also have similar kind of situation and I am thinking to the approach you have used.I have some questions.
    1 We should use BPM only when it is required.
      Using BPM wont effect the performance of the 
      system.
    2 If we are combining 6-7 interfaces  
      using this approach ,how it will effect the 
      performance.In case 2-3 interface are having
      very huge data.Then should we go for this
      approach.Is the performance issue will be on 
      adapter side or IS.

    3. We should have the same file structure for 
       all these interfaces ?

    (0) 
    1. Ravikumar Allampallam Post author
      1.We donot use many ccBPM but we use 1 generic + interface specific BPM.In real time scenraios many times we need ccBPM for every interface.

      2.We need to design appropriate number of file adapters instead of 1:1.

      3.It is not required to have the same structure.It works for any file structure.

      (0) 

Leave a Reply