Proxy custom fields empty on test

[Former Member]

To get several custom fields from our backend into the SRM system, we have enhanced standard proxy PurchaseRequestERPSourcingRequest_In on both sides. The proxies on both sides have been regenerated and activated.

Backend to PI --> success, custom fields are populated using a BAdI

In PI --> success, custom fields are populated as expected

PI to SRM --> the custom fields are empty

The XML message that is coming in from PI is correct, the fields are populated. So the next step is to see what happens when testing the proxy manually. I save the XML message and change the document number to make sure it is unique and not interfering with anything else. Select the proxy above and test, while selecting the option to debug.

In the debugger I see that immediately after I enter the 'execute' method on SRM side, the custom fields are empty. So they're there in the XML, but the moment I try to process them, I get empty values.

I've tried regenerating the proxy, the message type and  the individual fields, with all I get the message that nothing has changed. The DDIC structures in SRM are all correct (containing the custom fields) and activated.

What am I overlooking here?

[marksmyth · Accepted solution]

Hello,

Are you developing this within the SAP delivered ESR content (I assume some SRM content)? If you make changes to SAP delivered contents, which use a http://sap.com/..... namespace, you may not see the changes reflected in your proxy.

The recommended approach is to copy the SAP standard ESR objects which you wish to use into your own SWCV and namespace, do your customizations and then you will be able to use the corresponding proxy objects.

Regards

Mark

[Former Member · Accepted solution]

Hi Mark,

I'm not the PI expert (ABAP developer), but I do know that we have used the original object as a reference and added these new fields as an enhancement in our own namespace. By activating them in there, the message type of the original proxy was enhanced with those fields.

When I'm looking at the message type which is used, I do see our additional fields at item level.

In the XSLT transformation used to convert from XML to the message type, I do find the reference to our custom field. It maps the PI field zCostCenter to our enhancement field ZPP_PR_Z_COST_CENTER:

    <tt:cond s-check="not-initial('ROOT.ZPP_PR_Z_COST_CENTER')">
     <tt:ref name="ROOT">
      <n0:zCostCenter tt:ref="ZPP_PR_Z_COST_CENTER">
       <tt:deserialize>
        <tt:assign to-var="_C_NIL" val="' '"/>
        <tt:d-cond>
         <tt:attribute name="xsi:nil">
          <tt:read var="_C_NIL" map="xml('true', '1') &gt; val(C('2'))"/>
         </tt:attribute>
        </tt:d-cond>
       </tt:deserialize>
       <tt:cond-var check="_C_NIL!='2'">
        <tt:value/>
       </tt:cond-var>
      </n0:zCostCenter>
     </tt:ref>
    </tt:cond>

Added XSLT details

[Former Member · Accepted solution]

Turns out it had something to do with the namespace, but not for generating the custom fields.

The Integration Builder automatically enters the namespace of your data type enhancement in the XML Namespace field. You can enter a different XML namespace in this field if you want. The XML namespace avoids naming conflicts between customer fields and fields that are added later by SAP.

You have the option of manually entering a namespace whenever you create an enhancement. The PI consultant did not do that initially, what apparently resulted in conflicts (which we couldn't see when processing).

He has now entered a custom namespace and the issue is no longer there! The custom fields are now properly populated in the proxy message type