Problem with missing field in SOAP response

[Former Member]

Hello!

We implemented a simple "Integrated Configuration" with a function

block

in the backend and a SOAP Interface as the calling Interface. I

attached

a screenshot where you can see, that the field FLAGSHIP is missing in

the Response. First, there is for sure data where the field is filled,

and even if it is not filled, it should be seen in the SOAP Response,

just like the others! Could you have a look at this, because everything

Looks fine from here .. the function block has all the necessary fields

and can be tested successfully!

Does anybody have an idea, what could be wrong here?

Thanks and BR, EF

[Former Member]

Hi,

Let me just understand what you are trying to do. You are call the Webservice (Sync) and you are expecting a response. Send a field but not getting it back in the response? Is this correct?

If it is correct, it means that the 3rd party is not sending it back or they are and it is being removed because it is empty or whatever reason it might be.

Ask the third Party to have a look at what they are sending back because you are not receiving all the fields you are expecting?

Regards,

Jannus Botha

[Former Member]

Hi Jannus!

Yes, i simply call the Interface, and normally i get back a big list of data; as you can see in the screenshot, all fields are included, except the "Flagship" field! This is curious, because if no data is coming from a field, then i still can see the field in the Response. E.g. KLABC is such a field ... it is always empty, but it can be seen in the Response. The next Problem is, that the field "Flagship" is not empty in some cases, but even there, the field is missing. It is simply not in the Response, but i have no idea why? The backend is on of our Servers, and if I try to call the function block in SE37, then the field is there! I also built the PI Service with the structure of the Function Block, so there should be no Problem with inconsistencies, etc.

[Former Member]

Hi,

Can you please explain the process of the interface?

For example who is the source and target? What are the transfer protocol for both etc?

It might be a caching problem and make sure that everything has been activated. Do a full cache refresh and let me know the result please.

Regards,

Jannus Botha

[Former Member]

Hi!

The caller is a JAVA program which uses a SOAP interface. PI then calls a function block in the backend ECC system and responds synchronously via the SOAP interface to the caller. E.g. the JAVA program simply calls the interface with no parameters and gets back a list of retailers, in our case! Now, the WSDL file has all the necessary fields, and so does the function block. But, whenever i try it via SoapUI, then this single field is missing I already did a full cache refresh, but the problem persists! I added the structure of the function block here:

[che_eky]

Hi,

Use the message monitor to view the response message from ECC, does it include the missing field? Next use the message monitor to view the response message from PI to SOAPUI, does it include the missing field? This will help you identify where the field is being lost or dropped.

You need to identify at what stage the field is disappearing.

Che

[Former Member]

Hi!

I tried to look up the messages via SXMB_MONI transaction, but it seems that messages from "Integrated Configuration" projects do not show up there! Where should i look otherwise?

Thanks!

[suman_saha]

Hi,

Have you imported WSDL or XSD or created the data type in ESR?

If you have created in ESR,have you added this field afterwards?

You may remove the field and active,again add and active.

Mostly it happens due to metadata mismatch!

Suman

[suman_saha]

You should check in runtime workbench.

http://<host>:<port>/rwb

[Former Member]

Hi!

I imported the function block via RFC import to PI and then created the Integrated Configuration. Afterwars i created the WSDL via the wizard and used it in SoapUI.

[iaki_vila]

Hi Elmar,

SXMB_MONI is only for for IE messages try like Suman pointed.

I think is a cache problem although you have complete CPA cache refresh (http://host:port/CPACache/refresh?mode=full). Have you tried to delete the ESR metadata, activate the changes and finally import again the BAPI?.

Regards.

[nabendu_sen]

Hi Elmar,

Most probably RFC Response field which is mapped with <Flagship> is not coming back from SAP ECC. Thats why <Flagship> field is not getting populated at SOAP Response side in Mapping.

Do the following:

Step 1: STOP and START the RFC Communication Channel at RWB and test.

Step 2. If not resolved with Step 1, Re Import RFC in ESR and activate Imported Archive - RFC, Message Mapping and Operation Mapping.

Step 3. If not resolved check UNICODE settings at SAP RFC Connection at ECC and PI RFC Adapter.

Step 4. Check

Regards,

Nabendu.

[Former Member]

Hi!

I restarted the channel - no effect

I built the whole Project new from scratch (delete all mappings, objects, Service Interfaces, etc.) - no effect

Unicode Settings are fine - no effect

If I set a fixed value for the field in message mapping, the field appears! Even a call of the function block in SE37 (in the backend) delivers a result for the field ... Is there a way to track, WHAT data is coming from the function block to the PI System?

BR, EF

[suman_saha]

Hi,

To debug you can set logging parameters to check the response. It may be helpful to track.

Otherwise debug the RFC code using the same user id which you have used to send data from PI to ECC.

Process: Set a external debug point inside RFC. Send data from SOAP UI. Whenever data reaches to ECC,the debugger will be on and you can easily track what is happening inside the RFC code.

Regards,

Suman

[JaySchwendemann]

Are you on dual stack PI or single stack PI? If dual stack, try RUNTIME parameter LOGGING_SYNC = 1. If that is set, SXMB_MONI of PI should contain the message. Maybe you can track from there

Other option would be the use of XPI Inspector, select template 50 and give your RFC receiver channel name and reproduce.

Cheers

Jens