EOIO with dynamic queuename possible in SOAP sender ?

[Former Member]

The customer has a requirement to pass a queuename parameter within its SOAP message, and our PI SOAP sender adapter (which must use QoS EOIO) should use that queuename. Apart from the question if that makes sense:

is that possible at all ?

If yet, what flags do I have to set in the SOAP sender adapter (query strring, keep attachments and so on) ?

PI 7.0

CSY

Edited by: Christian Sy on Jan 13, 2011 10:14 AM

[RaghuVamseedhar]

Hi Christian Sy,

I understand, your customer requirement is to dynamically dictate QoS EOIO sender queue name by SOAP message.

As far as I know, it is not possible [Link1|http://help.sap.com/saphelp_nwpi711/helpdata/en/48/3555240bea31c3e10000000a42189d/frameset.htm]. As you said, it does not make sense. Customer may be worried about the sequence of message processing. You can convince them, that if we use QoS EOIO and define queue name [Link2|http://help.sap.com/saphelp_nwpi711/helpdata/en/7b/94553b4d53273de10000000a114084/frameset.htm] in sender SOAP channel, sequence can be guaranteed.

Regards,

Raghu_Vamsee

[stefan_grube]

You find the answer in SAP note 856597

[Former Member]

SAP note 856597 mentions the URL parameter QueueId, that is good to know. The problem for the customer is, how can he set that value dynamically ? He is sending from a PI system, he has the queuename somewhere available in the message. But the SOAP receiver channel needs a hardcoded URL (or not ?). Is there a trick to set the queueID URL parameter dynamically (apart from writing an adapter module) ?

We have tested other ways (passing the queueName in SOAP header, or encoded header), but that did not work.

It is a PI to PI scenario which uses SOAP receiver adapter and SOAP sender adapter (not PI adapter, for some reason customer did not want to use it).

CSY

[stefan_grube]

> It is a PI to PI scenario which uses SOAP receiver adapter and SOAP sender adapter (not PI adapter, for some reason customer did not want to use it).

It would be nice if you mention this important fact in the beginning.

Because you get forget evrything I wrote before.

Just check 'keep headers' and 'use encoded headers' in sender and receiver channel, and that's it.

[Former Member]

Interesting. We tried that option before, but got the following strange exception, so we thought that is the wrong way. The sender is PI 7.1, the receiver is PI 7.0.

Is it a problem with the different versions, or a problem with the namespace name (e.g. the "Minus" character) ?

Message-Verarbeitung fehlgeschlagen. Grund: com.sap.engine.interfaces.messaging.api.exception.MessagingException: SOAP: response message contains an error XIServer/UNKNOWN/MalformedMessageException - Unexpected length of element <sap:Main><sap:Interface @sap:namespace> = http://abcde.com/rd/GL/PA/B2B/SU-OP_IF001-GL/PurchaseOrder/10; nested exception caused by: com.sap.aii.messaging.util.XMLScanException: Unexpected length of element <sap:Main><sap:Interface @sap:namespace> = http://abcde.com/rd/GL/PA/B2B/SU-OP_IF001-GL/PurchaseOrder/10 at com.sap.aii.messaging.mo.xmb.XMBMessageHeader.unmarshal(XMBMessageHeader.java:1184) at com.sap.aii.messaging.mo.Message.reparseRootDocument(Message.java:964) at com.sap.aii.messaging.net.MIMEInputSource.readSOAPPart(MIMEInputSource.java:624) at com.sap.aii.messaging.net.MIMEInputSource.decodePart(MIMEInputSource.java:616) at com.sap.aii.messaging.net.MIMEInputSource.readBody(MIMEInputSource.java:382) at com.sap.aii.messaging.net.MIMEServletInputSource.parse(MIMEServletInputSource.java:58) at com.sap.aii.af.mp.soap.web.MessageServlet.doPost(MessageServlet.java:390) at javax.servlet.http.HttpServlet.service(HttpServlet.java:760) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401) at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266) at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:387) at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:365) at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:944) at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:266) at com.sap.engine.services.httpserver.server.Client.handle(Client.java:95) at com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175) at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33) at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41) at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37) at java.security.AccessController.doPrivileged(Native Method) at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:100) at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:170)

CSY

[stefan_grube]

In PI 7.0 the namespace length was restricted. I do not know the allowed lenght, but it seems to be too long in your scenario.

Has the interface in both systems the same name?

[Former Member]

I remember a similar issue with namespace length in my projects, which occured when importing an XSD. SDN/OSS says the maximal namespeace length in PI 7.0 is 60 characters, which explains our issue (we have 61 chars, argh):

The interface has not the same name in both systems. In the receiver system (the 7.0) the namespace is shorter. But that does not seem to help. I tried to add an explicit sender agreement for the SOAP channel, did not help either. The error seems to occur at an earlier stage in the communication.

Even changing the receiver agreement header mapping in the sender system probably would also not help (?), because there we can set only partner and service-name.

The customer will surely not change his namespace name, development is finished. Is there any workaround ? The OSS note 901988 does not mention anything about SOAP call, only about XSD/WSDL import.

CSY

Edited by: Christian Sy on Jan 25, 2011 4:26 AM

Edited by: Christian Sy on Jan 25, 2011 4:28 AM

[stefan_grube]

When you want to use "keep headers", then this will be a PI-PI connection as you have it with XI adapter.

That means: sender and receiver system, interface and namespace must exist in both systems equally.

> "The customer will surely not change his namespace name, development is finished."

Sorry, I cannot accept this. The scenario is not working, so how can a customer say: Development is finished?

Before you continue wasting your time (and customers money), convince the customer, that an XI adapter would be the best solution. SAP PI experts get money to find the best solution for the customer. So do it.

[Former Member]

It a very large customer, which uses this namespace for his purchase order implementations, not only for our interface. So chances are small we can get an exception, we will try.

BTW, I expect that a large part of my wasted time is because SAP is not able to document its PI product enough, and is not able to implement it in a way that developers are really productive with it (best example is the whole grahical mapping area with its infamous context architecture). The existing Java GUI for IR and ID has so many shortcomings. I hope this will get better when all developer tools will have moved to Eclipse (> 7.3).

If SDN would not exist many people often would be lost without the help of PI cracks like you. Even experienced ones. Of course the product is very complex, but then SAP should document it better, please. E.g. if there are namespace restrictions, then put this information in the SAP help where the affected functions are descibed, and not only in an OSS note. This would really save us time.

Thanks for your inputs, I really appreciate it.

CSY

[stefan_grube]

> BTW, I expect that a large part of my wasted time is because SAP is not able to document its PI product enough, and is not able to implement it in a way that developers are really productive with it (best example is the whole grahical mapping area with its infamous context architecture).

Sad, but true.

The whole PI-PI connection is not documented at all.

A lot of customers use HTTP adapter just because they know, how it works.

Maybe you try HTTP adapter also?

Here you are free to use a different interface name in both systems, you can easily add the queue-id to URL parameters with dynamic parameters.

[Former Member]

Unfortunately we have to pass an additional PDF attachment with the message, that is why we use SOAP and not HTTP.

Another idea is to set the queue-parameter in the SOAP URL of the sender system dynamically, but this is probably only possible with an adapter module (?). Java or graphical mapping cannot set this parameter, right ?

CSY

[stefan_grube]

> Another idea is to set the queue-parameter in the SOAP URL of the sender system dynamically, but this is probably only possible with an adapter module (?). Java or graphical mapping cannot set this parameter, right ?

You can only set the whole SOAP URL in ASMA, but that means you have to hard-code it instead to use the configuration.

In HTTP adapter you can HTTP header and URL parameters, in SOAP adapter you can set only HTTP headers, but no URL parameters.

Is there really no chance to use XI adapter? All you need to do is creating the exact same interface and namespace in PI one as reveiver interface, what is used as sender interface in PI two and assign the same Business system.

[maciej_jarecki]

HI

i have url from test from soapUI

http://<host>/XISOAPAdapter/MessageServlet?channel=:bsys_name:cc_name&version=3.0&queueid=myqueue

i set in sender SOAP CC

keep headers

use encode headers

use query string

and QoS EOIO and queue name

And in sxi_monitor i see queue set in CC

what is wrong ?

Kind Regards

Maciej