case design challenge - sync/async?

[Former Member]

Hi experts,

I'm participating in a huge project with a lot of business cases and I have a design challenge that I have to find the best solution for.

My client uses Documentum system to store documents; all it does is to receive real documents with their attributes to use as meta-data and return a number for successfully stored documents. So all I have to do is to send a message that contains document attributes with the document itself as a attachment with a web service.

I'm supposed to integrate Documentum with SAP systems and Proxy-XI-SOAP will be used in this scenario.

The challange is, the attached documents will be of 1 - 10 MB size. The interface was proposed to be a synchronous interface, so as the user chooses the document to upload and enter its attributes and click send from SAP, he will wait until the document is uploaded to Documentum and a number is sent back from documentum to SAP as a response message.

I don't think a synchronous interface should be used in this case because the user will have to wait until the document is uploaded online and errors might occur if response message does not return successfully. An async interface that will upload it in background seems like a more convenient way. But if I use asynchronous interface to upload the document, I will need another asynchronous interface that is to be triggered from Documentum to send back the document number.

AND for to the devil in the details, I need to be able to trace for which uploaded documents I received a document number, so these two interfaces needs to be technically related somehow. A simple BPM with only send/receive steps can do the job, but I would like to hear your opinios. What options are available for requirements like this, what is the best option to follow?

Thank you for your input.

Regards,

Gökhan

[Former Member]

Thank you for your kind input.

Although I have not finilized my decision, I can say that I have changed my mind about passing the documents over XI at all. Apart from filling the XI database quickly and sacrificing performance, it also seems like carrying documents over XI is like using my Mercedes for carrying cargo.

Instead, I think it would be wiser to use Web Service Framework of SAP systems to create a point-to-point connection from SAP to Documentum to upload the document and get the document link back. But I'm lacking some experience here. This scenario is triggered from a workflow, so when the workflow calls the sync interface, it will be waiting for the response. I don't want this to happen, the workflow needs to continue and can get the response back at any later time. Is this possible? If yes, how to implement it? Also, does SAP WS Framework supports attachments?

Regards,

Gokhan

[VijayKonam]

Gokhan,

If you are planning to use web service run time, then the Web service provided by documentum must asyn in order not to make ECC wait for the response. If it is available directly then no problem. Otherwise some development might have to happen at documentum side.

I would use XI in between for this requirement where I have constraints on development at documentum side.

VJ

[Former Member]

Hi Vijaya,

FYI, SAP WS Framework only supports synch. communication. I only need to figure out if it supports attachments or not.

Regards,

Gokhan

[Former Member]

Hi Gokhan

Looking at the requirement its a high volume data transfer and system is responsible for bringing the attributes and response for successful messages.

If we think in a way that transfer messages not as and attachment using File adapter based approach then too documents movement will cause high volume data movement and increase the cost for client. Using BPM it will hit performance.

If i think of using XI for brining the attributes and transfer the document from documentum system so thats low volume data and sync response duration can be very small.

Now looking at ways to transfer data bypassing the adapters is proxy. Java/ABAP or Scripts. ABAP proxy again if you have network constraints need to do development and its not a good practice to open any ports on the ERP system for FTP etc. Now Java proxy can be ideal choice for this as using this dynamically attributes can be provided to pick the file and move. Proxy code can run on XI box where there is no db so ports can be open for it.

Now how to execute this. Sender sends attributes to Java proxy- Proxy moves file and response for successful documents. XI has less message size and native Java do a binary file transfer faster comparing to adapters or applications. But dependency exists for the response over Sync call. I think reducing volume and time of transfer this helps. Logging is one important this need to be considerd while doing such development.

Thanks

Gaurav

[VijayKonam]

Hi Gokhan,

I would even consider the amount of data being transferred from SAP to Documentum with respect to the document sizes. I would like to think in the direction where, instead of sending the documents (huge in size) as attachements, what if the proxy can place them at a network location accessible by documentum and PI passes only the link to documentum web service from where it will upload the file to documentum? This way the amount of data being exchanged at XI (unnecessary persistance) could be avoided.

Coming to the Async and Sync situation, going with Sync would be sure a problem since the time that the user has to wait depends on the document size being uploaded. Asyn - Sync Web Service Call and an Asyn update to SAP would be the solution that I would consider. But in this case the USer has to run a report or something in order to look at the documentum response as success or error.

Thanks.

VJ