TServerLocation SOAP Receiver Adapter

[helmut_skolaut3]

I have a problem with SOAP Adapter using TServerLocation. I have read all the wikis and posts not finding the problem. When I am passing into the correct TARGET URL statically the communication works perfectly.

When I look into the Dyn Config in the monitoring, the URL is passed through with the mapping correctly:

The Channel is configured like this

But looking into the channel monitoring, the URL is not taken from the Dync Conf, it's picking up the static URL:

Is there anything I have overseen?

Regards

   Helmut

[vadimklimov]

Hi Helmut,

You should populate value of message attribute TServerLocation with the required target URL somewhere before SOAP adapter is called - most commonly this will be done within mapping. Here is an example of a UDF that performs this (assuming "url" is a String variable holding the required target URL):

Map map = container.getTransformationParameters();
DynamicConfiguration conf = (DynamicConfiguration) map.get(StreamTransformationConstants.DYNAMIC_CONFIGURATION);
DynamicConfigurationKey asmaSoapUrl = DynamicConfigurationKey.create("http://sap.com/xi/XI/System/SOAP", "TServerLocation");
conf.put(asmaSoapUrl, url);

You may look at SAP JavaDocs to get some more examples: Generated Documentation (Untitled).

Regards,

Vadim

[helmut_skolaut3]

As I said, I have no issue with the mapping, see the first picture. I have now changed the scenario using Plain HTTP instead of SOAP and it worked fine with the adapter specific attribute. So I am assuming some bugs in the SOAP channel not reading the Dync Conf.

[vadimklimov]

Hi Helmut,

You are right - I mislooked your first screenshot. I remember I was using the described approach for SOAP receiver adapter and it worked well for me. I've just tested in internal PO 7.31 system - and it works well for me.

Mapping configuration with UDF for setting message attribute TServerLocation:

SOAP receiver channel configuration:

As you see, I specified a target URL "http://e107184.emea.arm.com:8080" in channel, which is going to be replaced by "http://e107184.emea.arm.com:8080/TestService". Receiver is a Tomcat server - there in logs, I can see that /TestService was called:

Which PI release do you use? Is it possible for you to test scenario with SOAP receiver channel, but using Java-only Integrated Configuration object and not dual-stack scenario configuration? Can you collect runtime trace for mapping and receiver communication channel (e.g. using XPI Inspector) - probably it will be possible to get more details from there.

Regards,

Vadim

[markangelo_dihiansan]

Hi Vadim,

I think this is normal behavior. Can you show a screenshot of cc monitoring to show that the target URL is indeed replaced by the new value?

Regards,

Mark

[helmut_skolaut3]

Hi Vadim,

thanks a lot for your help. My release is still 7.11 but I did this as a PoC for my upcoming new 7.5 system, so I am assuming that is is simply a bug in the old release.

If someone else is knowing that the problem solved with an higher version, please let me know ... Otherwise using the Plain HTTP adapter is also fine for me 😉 This is the proof that the adapter specific attributes are stored correctly with my ABAP mapping.

I was hoping that I might had somewhere a typo or a hidden checkbox needs to be flipped, but looking at you screenshots, I am convinced that it's simply a bug in my 7.11.

Regards

   Helmut

[vadimklimov]

Hi Mark,

Unfortunately, a PO 7.31 system where I checked dynamic configuration for an attribute TServerLocation, is not much up to date, so I couldn't collect convenient HTTP trace using an option for HTTP tracing for receiver adapters described in SAP Note 1904944, and audit log of a message doesn't have indication of called URI. XPI Inspector trace does have indication that attribute was set to the desired value (in my case, "http://e107184.emea.arm.com:8080/TestService"). What I did is, using Wirehark, I collected a network trace from application instance of that PO system and checked which network traffic was coming from PO application instance to a called target server - and there I can see that PO made an HTTP POST call to a URI /TestService on a target server (as expected, with target URL substitution in PO):

And I'm pretty sure it is exactly a call coming from this interface, since there is no other one using this SOAP endpoint (I created a channel and used that endpoint just for checking an issue that Helmut described).

Regards,

Vadim

[vadimklimov]

Hi Mark and Helmut,

I have just moved this test configuration to another internal system, which is PO 7.4, and tested again. Here I have more details in XPI Inspector trace and in message audit log. Target URL in communication channel and its replacement done in UDF for message attribute TServerLocation are exactly the same as I used yesterday.

In message log, I can see it is stated that target URL is "http://e107184.emea.arm.com:8080/", which is the one specified in communication channel and which is wrong:

But XPI Inspector trace indicates a right called endpoint  - "http://e107184.emea.arm.com:8080/TestService":

(please ignore connection error - new PO environment has no network access to the specified target host, but it is not a point in this test - I wanted to replicate exactly identical endpoint configuration in UDF / channel not to bring confusion)

Thus, I would assume an entry seen in message log is specifying the wrong target URL because it is created at runtime based on communication channel configuration, and target URL substitution happens afterwards (as seen in XPI Inspector extract above) and doesn't get reflected in message log. Actual HTTP call is sent to the correct (substituted) endpoint.

Helmut, do you have possibility to run your test again and check from network or HTTP trace what actual target endpoint is called? Probably, there is no bug in your system and the expected endpoint is called correctly, but a bit misleading reflection of a called target URL in message log.

Regards,

Vadim

[former_member183816]

Your configuration is fine, it's a bug. I am sure, you must have tried,

1. Check extra spaces in "TServerLocation"

2. Provide "TServerLocation" parameter in headername1, headername2 and headername3 ,one by one and simultaneously.

3. Provide "*" in target url.

4. Deleting and recreating the channel.