Architecture Input Reqd.

[Former Member]

Hi guys, I have a requirment for an interface where data would come from 50 different non SAP internal systems into XI which inturn creates orders Idocs in ECC. The FTP protocol is against the integration policy of the client. We have thought of installing the J2EE decentralised adapter engine on each of the 50 source systems and pass the data to XI integration engine using http. In theory, this solution would work but I have few questions around this approach.

1. Has anybody any experience of using so many decentralised adapter engined with a single Central XI integration Engine? would it be performance efficient?

2. what would happen to the decentralised adapter engines if XI central instance goes down? would the messages be persisted in the adapter engine and when XI comes up, the messages would be processed?

3.Could there be any better solution for this requirement?

Please help.

[JoelTrinidade · Accepted solution]

Hi Ethan,

Ravi Kanth Talagana has very much answered your question taking your point of view. I however have a different view which would involve FTP.

You have mentioned

The FTP protocol is against the integration policy of the client.

.

I have no problems if you go with creating 50 different decentralized engines but then I wonder whether you have taken into account the amount of effort in creating, installing and maintaining so many engines.

If you client has some insecurities about using FTP because they fear data theft then you should educate them about usage of SFTP (securing ftp with SSH) or FTPS (securing ftp with ssl ). Its only a matter of client education.

Advantages would be:

1) Security are taken care of this way.

2) Maintenance is negligible.

3) Improved performance and no problem about message getting lost.

4) Archive facility available with the adapter itself.

5) Integration is less complicated as compared to using http.

6) Purpose of having a central place from where data can be collected on the similar line as XI which acts as a central repository makes integration seamless .

Regards

joel

[Shabarish_Nair]

>

> Hi guys, I have a requirment for an interface where data would come from 50 different non SAP internal systems into XI which inturn creates orders Idocs in ECC. The FTP protocol is against the integration policy of the client. We have thought of installing the J2EE decentralised adapter engine on each of the 50 source systems and pass the data to XI integration engine using http. In theory, this solution would work but I have few questions around this approach.
> 
> 1. Has anybody any experience of using so many decentralised adapter engined with a single Central XI integration Engine? would it be performance efficient?
> 

so if you mean there are 50 systems and the plan is to create 50 decentralized instances, I say its stupid.

go for one decentralized instance that will handled all these 50 interfaces and not 50 instances

> 2. what would happen to the decentralised adapter engines if XI central instance goes down? would the messages be persisted in the adapter engine and when XI comes up, the messages would be processed?
> 

Already answered. It works exactly the same as the central instance so do not worry about messages being lost.

> 3.Could there be any better solution for this requirement?
> 
> Please help.

Why go for a decentralized instance when you are using HTTP towards the end?

use the central instance itself with the HTTP plan (so you dont need FTP). Are there any specific reasons for going the decentral way???

[Former Member]

Thanks for your quick replies. My answer to your suggestions:

1. Currently these systems are sending data using MQ. the business doesnt want to change anything on these systems and send the data to a single server on which we can install the decentralised adapter engine. Hence the proposal for individual decentralised adapter engine was given. for using one DAE for all the systems, we need to have a file system where all the business systems can dump the files on which we would install the DAE.

2. Towards the end, its an IDoc solution. The http connection would be between DAE and the XI integration Engine. for http connections, from all the sender systems, we need to check if the systems are capable of sending data through http.let me know bit more info if its handy, I shall look at SAP documentation on this anyway.

3. SAP XI doesn't provide SFTP adapter, this approach is discarded as we would need a third party SFTP adapter to use SFTP. The FTPS is not as secure as SFTP, hence ruled out.

Please let me know your comments on above.

[former_member181962]

Hi Ethan,

Regarding your 2nd point:

>

> 2. Towards the end, its an IDoc solution. The http connection would be between DAE and the XI integration Engine. for http connections, from all the sender systems, we need to check if the systems are capable of sending data through http.let me know bit more info if its handy, I shall look at SAP documentation on this anyway.

YOu have mentioned that the all the sender systems use MQ.

So, you can use the JMS adapter on the DAE.

One the data is passed to the DAE, the sender system's responsibility ends.

hence the question of whether or not the sender system is capable of sending HTTP messages, can be ignored.

Regards,

Ravi Kanth Talagana

[Former Member]

Ravi,

Sorry, i think I didnt make it clear. Currently they use MQ, but we want to remove MQ and use XI.

[Former Member]

Hi guys,

If we use DAE with the XI central instance. For any outbound interface from SAP e.g. SAP ->XI ->DAE ->legacy, if the DAE goes down, what will happen to the message ? Will the message go in error in SXMB_MONI transaction? If yes, what would be the error ? would it be 'no receiver found'?

[VijayKonam]

I might sound dumb. But in the first place, is there a need for DAE? what other protocols the legacy systems could support? Though there are 50 legacy systems if all the systems use same XML format, why dont to you look at any other adapters that support? were these items given a thought..?

VJ

[former_member181962]

Hi Ethan,

1.As an answer to your first question, i do not think there should be any performance issue since each decentral adapter is dealing with only one system and the prixmity of the Decentral adapter engine infact improves the performance (At least in theory).

2.A decentral adapter engine works exactly in the same way as a central adapter. hence the messages will be persisted and will be sent when the central XI instance is UP again.

3. Will wait with you to see if there are any better options.

Regards,

Ravi Kanth Talagana

[shivhare]

Hi Ethan,

I think use one common FTP server for all 50 interface . and transfer data from non SAP system to common FTP server with the help of file transfer protocal .

you can map common FTP server directory to all NON SAP interface ..

Regards,

Amit