XML-XI-R3

[Former Member]

Hi everyone,

We are developing an interface XML-XI-R3. In R3, we are updating a custom table. The sender system gives us an xml file with list of data to be inserted, updated and we read that doc - in xi and call RFC which updates and return back response. We would send this response as xml file back to the sender. The interface is not synchronous - they dont expect the response immediately.

My question is,

1. Do I need BPM ?

2. Bapi return has to return the whole message structure for each row that is being updated - how do I do this?

3. Can anyone just give a rough step by step procedure on design and config?

I do have some ideas on this interface. But I want to confirm the approach with others experiences.

Any help is greatly appreciated and I always give points promptly..

Thank u

Thilothama

[Former Member · Accepted solution]

Hi,

You can just try this suggestion.

1.Create a <b>synchronous</b> interfaces for "File" and "RFC" in Integration Repository.

2.Dont worry about the File adapter which is asynchronous.

3.In the Mappings, let your request mapping be normal graphical mapping.

4.In the response mapping, you can use JAVA mapping and use Java IO classes to write the response from RFC as xml, on to the server loction or any place u intend.

5.In ID the configurations are as usual.

This can solve ur purpose efficiently.

regards,

P.Venkat

[sam_raju]

Hi Thilothama,

>>>><i>1). Do I need BPM ?</i>

This depends.

You can make your scenario synchronous with Sync RFC call and send the response back to the sender right away and build an alert mechanism using BPM to nitify the sender in case there is a failure in the RFC call .

If you don't want to send the response back right away, then you have to configure your interface with QOS EO. In this case, you will not get anything back from r/3. As you mentioned that the sender is not expecting the response right away, you can either build the logic using BPM or you can build another interface in XI just to send a weekly status of your upload.

>>>>>><i>Bapi return has to return the whole message structure for each row that is being updated - how do I do this?</i>

You have to have the logic in your RFC source code and build a synchronous Scenario in XI to get the status of the uploaded records.

>>>>>>>3)<i>Can anyone just give a rough step by step procedure on design and config?</i>

There are many blogs in this regard. Do a search on the Forum

Hope this helps.

Rgds,

Sam Raju

[Former Member]

Hi,

a good suggestion which originally came from Michal is to call another RFC in your BAPI / RFC after the processing to return the results. In this case you'll have two asynchronous XI interfaces, one for the request data and one for the response data, and no need at all to use a BPM. I can't repeat often enough that BPMs should not be used for the sake of alerting as suggested by Sam. Independent from what you are going to use (synchronous, asynchronous, with BOM, without BPM) you will be able to use the alert framework to direct errors to the responsible personnel.

If you need some logic to create a special file name so that the sender can identify the response file, you should look into constructing the file name from the payload.

So my suggestion for your scenario would be File -> XI -> BAPI -> RFC -> XI -> File. If your R/3 is on WAS 6.20 or higher, you might want to consider using Proxies instead of RFCs.

Regards

Christine

[Former Member]

Christine,

So I can use proxies which gets the request and gives back response - how do i write this to file???

Also can we use proxies even if XI is in WebAS 6.40 and R3 is in Web AS 6.20??

Message was edited by: Thilothama v

[moorthy]

Hi,

If you are using Proxy then it will be Proxy to File Scenario,-i.e to write into files.

<i>>>>>Also can we use proxies even if XI is in WebAS 6.40 and R3 is in Web AS 6.20??</i>

Pls go thru following link.

http://help.sap.com/saphelp_nw04/helpdata/en/2b/f49b21674e8c44940bb3beafd83d5c/frameset.htm

Regards,

Moorthy

[Former Member]

Thilothama,

what you will do is to write two asynchronous proxies. One is an inbound proxy putting data into R/3 and one is an outbound proxy sending the result out of R/3. Now in the programm you write for the inbound proxy you'll first process your data and then take the results, put them into the structure of the outbound proxy and call that outbound proxy at the end of your program. Then your interfaces in XI are all asynchronous, the connection between request and response is made within the proxy.

There is no limitation to use proxies between XI3.0 and a WAS 6.20 based system. You just need to make sure that you use Message Protocol XI 2.0.

Regards

Christine

[sam_raju]

Hi Christine,

Okay. I agree with you on not using BPM for the sake of alerts. What I meant by alert mechanism is notifying the status/failure back to the sender and not just alerting the responsible personnel. In Thilotama’s scenario, the requirement is to send the response as an XML back to the sender. Here the sender can be an external party and may be requesting the status notification in a certain message format. The sender may be sending several updates everyday with a unique Transaction ID with a "predefined deadline" or a "time to process".

The solution you are suggesting is to call another RFC in your BAPI/RFC after the processing to return the results with two asynchronous interfaces in XI without BPM. Let’s look at a couple of situations below.

What happens if your 1st RFC/BAPI fails or system hangs just before calling the 2nd RFC? If there are several updates each day, how would you send the response back to the sender for a specific transaction with a predefined deadline to send an alert or failure notification?

How would you notify the sender when there are a couple of updates which come one right after the other, say, the first one being successful but the second one failing just before making the 2nd RFC call?

This is the case in many of the B2B Scenarios, where the sender sends a request message and waits for a response message.

With BPM, you should be able to define and monitor whether the response message is received within the predefined deadline. This can handle the above error situations efficiently.

The BPM, with unique correlation, can take care of the orchestration of request and response messages and handle the error situations within a deadline and terminate with an error process.

The above solution with BPM can be handled in the following way.

The first step in the BPM receives the request message and activates the correlation. This correlation links the request and response message by means of a Transaction ID (Date and Time Stamp). The subsequent “send” step sends to request message from SAP. The receive step to receive the response from SAP uses the correlation. A subsequent send step then sends the response back to the sender. In case of errors like above when the deadline is not met you can define Alerts or terminate the process with errors send ing failure notification to the sender in a certain message format.

It is not a question of using or not using the BPM but it is a question of how efficiently you can handle the errors in the above scenario.

Rgds,

Sam Raju

[Former Member]

Hi Sam,

i agree that BPM comes into the picture when you need deadline handling, but the poster didn't really state that he needs deadline handling. And from what i see on the forum here is that a lot of people tell others to use BPM even if there is no specific requirement to do so or at least it is not known. I'm not really against BPM and in the scenario you mentioned it is really valid to use it, but i'm a strong believer in the Keep it simple and straightforward principle and that is why i repeat myself in saying that there is not necessarily a need for BPM if you want to have alerting or error handling. So if you go into a bit more detail next time you mention BPM with alerting / error handling, i won't disagree with you

Regards

Christine

[Former Member]

Ok..That was a good discussion.

My requirement does not even happen everyday. They send updates to the custom table on demand. So Initial load of the custom table through interface may insert more than 6000 records. After that any updates will come once in a week or a month.

My idea was XML - XI - RFC in which RFC has tables to get request and as well as return the response (BAPIreturn). I dont understand - why there should be 2 RFC?? here?? one rfc itself - cannot do everything???

Lets not talk about proxies or BPM as of now and if u use the above said simple scenario with one rfc - what will be the problem when it comes to error handling?? do i need transaction id and correlation approach?? if goign for BPM???

I dont need any deadline handling as well

Thank u both for doing such a useful discussion