Skip to Content
Author's profile photo Former Member



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


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.


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!!!!!!!!!!!!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      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 
      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 ?

      Author's profile photo Former Member
      Former Member
      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.