cancel
Showing results for 
Search instead for 
Did you mean: 

Handling Dynamic pay loads using a Single URL

Former Member
0 Kudos

Hi All,

I need to integrate SAP R/3 to a Third party web portal using SAP XI. Portal will communicate with 15+ messages. The third party portal is asking me to provide a single URL to send tje XML Messages. the problem is each message is having different structure from other. We have to recognize the message by seeing the header. The header (root node) will contain message number (like Msg01, Msg02, Msg03 and so on...) , . They have provided us a XSD file, which contains all the messages as complex type , which i can able to upload as External Definitaion. But in the message interface only one message i can use at a time as output message. i,e msg01 or msg03 or msg03 etc... . But the third part portal will send any of message out of 15 messages. So how can i generate single URL to accept dynamically any of 15 message. Also i am getting a confusion which sender adapter to use . Can anybody guide me how to handle this situation?

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi,

please clearify what should be done at first. Normally you will need different interface name, if it is for different purpose. As you mentioned there 15 different messages come from Portal it indicate actually 15 different interfaces. If you have to use one single fixed URL for portal as destination, you could just give one general name to cover all interfaces e.g. MI_OUT_PortalInterface and in the Receiver Determination step split the message according the HTTP header information. Depends which messages is sended from the portal you could configure one different Message Mapping and one different receiver system.

I think you have one HTTP communication here.

regards,

Hai

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi All,

Thanks for the quick reply. Third party Portal is not only integrated to XI, But also they have integrated to other applications. So they are not willing to change the present method as they are using for other applications. So it should be done something from XI part.

In my scenario, they will send XML messages to XI. Also from R/3 i need to send XML messages to portal Via XI. For that they provided me a WSDL and URL to send XML messages. Initially we planned to expose each interface as a webservice, so that they can consume. But they are asking all the interfaces under one URL. The problem comes here. When i raised a query they have given the following reply.

"The poratl messages / webservices are not based on RPC/Literal or RPC/Encoded. The messages use Document/Literal and therefore are not using any direct method calls. The broker will receive a document/literal messages and will forward this message to the given recipient (SAP XI etc). The recipient will parse the message, dissamble it's parts and will call the appropriate method in the business layer. In turn, a response message is send.

Which method eventually will be called is determined by the root element of the Soap messages body. For example msg04 has the root element msg04. After receiving the message, the method msg04 will be called.

For example:

a message from an recipient(XI) will be send to the messagepath http://localhost:<port>/MSG/<Recipient>. This url will be the same for all messages that are being send from an recipient to poratl so there is no need for other urls that hold the method name."

Stefan -- Already we thought of doing the way you told. But the problem is each message is having more than 500+ elements . They are very much complex to design all the messages under one node.

Hai Long -- Initially i should able to pick the message which i recieved, then only i can go futher reciever determination etc...

Please advice me there is anything else i can do?

Former Member
0 Kudos

Hi,

you can use one java mapping in the advanced receiver determination as I mentioned. Which does not need to have a unified message format.

****

Enhanced Receiver Determination

Use

You use an enhanced receiver determination to have a mapping program determine the receivers of the message dynamically at runtime. Instead of creating the receivers in the receiver determination manually, you assign a mapping to the receiver determination and this returns a list of receivers at runtime.

A typical usage case is if you do not yet know the names of the receivers at configuration time. In this case, you can define a mapping program, for example, which reads a list of receivers from a table or from the payload of the message at runtime.

*****

After Java Mapping you have already assigned the 15+ different messages to the right receiver you intend to send the request. You can just carry on with normal configuration from here, perform mapping if you need in the interface determination step. etc. Since you don't have one unified Message format for the 15 different messages, you probably need implemented all mappings in Java. Because message mapping does not work, since you have only one outbound interface from Portal (15 different requests are labeld with same interface name). Nevertheless, with java mapping it is not a problem to check the root node at first and carry out the wished mapping.

Summarize here a bit:

1. defined ONE Message Outbound interface e.g. MI_OUT_Portal for different Portal request (you could define this interface based on some random MT, does not matter at this point)

2. define one Interface mapping which map the MI_OUT_Portal to Receivers, Receivers is located in SAP BASIS (standard XI content from SAP)

In this interface you should have to refer one java mapping which read the XML payload from portal request and find out who is the receiver. This should be quite easy. You could even configure it in one external Database which msg goes to which receiver and find out it in the runtime.

3. You need mapping from different message typ to the wished receiver, these 15 request messages will probably has 15 different inbound interfaces, you will need 15 different interface mapping if every request message has to be mapped before it can pass through to the receiver application. These mappings could be done in one java mapping again.

4. configure Receiver Determination with advanced RD in Configuration with the Interface mapping which implemented in step2

5. configure Interface determination and receiver agreement

regards,

Hai

stefan_grube
Active Contributor
0 Kudos

Is the protal system not able to have an URL depending on message type, or are the portal guys just not willing to do so?

It 7.0 it is not possible to have mappings to the same interface with different message types (this will be supported with 7.1) so you need some workaraounds.

You could use a common structure like this:

root

-msgtp1

-msgtp2

-mgstp3

The root tag is provided by an XSLT/Java mapping. The mapping can no be created depending on the availability of the msgtp tags.

I hope that helps,

Stefan

Former Member
0 Kudos

:). Portal guys seems to be really lazy.

Maybe you could use one java mapping in advance receiver dertmination to find out which BuisnessSystem is the correct receiver and do interface determination from there on.

regards,

Hai