cancel
Showing results for 
Search instead for 
Did you mean: 

Receiver Determination Mapping Failing at Runtime

Former Member
0 Kudos

Hi there,

We have an issue where we have a functioning mapping, which takes an IDOC and performs a JDBC lookup to determine the receivers - it works in test mode and when we use the mapping as a standard mapping at runtime (both using the same data, lookup channel and database).

However when we try and execute the mapping as a receiver determination it fails with the following error in the trace;

Catching com.sap.guid.GUIDFormatException
at com.sap.guid.GUID.parseHexGUID(GUID.java:1047)
at com.sap.guid.GUIDGenerator.parseHexGUID(GUIDGenerator.java:111)
at com.sap.aii.ibrun.sbeans.mapping.MappingAccessBean.createParametrizationForMessage(MappingAccessBean.java:527)
at com.sap.aii.ibrun.sbeans.mapping.MappingAccessBean.executeMappingSteps(MappingAccessBean.java:229)
at com.sap.aii.ibrun.sbeans.mapping.MappingAccessBean.executeMappingAndReturnResult(MappingAccessBean.java:150)
at sun.reflect.GeneratedMethodAccessor2759.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)…

This is then shown as an error in ECC - other IDOCs are processing fine and we can see the IDOC hitting PI and trying to execute the Receiver Determination before failing with the above error.

We have tried refreshing the CPA Cache, recreating the JDBC lookup channel and refreshing the mapping cache with a 'non-change' to the mapping - but none of these have made any difference.

We are using SAP PI 7.4 single stack (AEX).

Has anyone else seen this behaviour? Or have any ideas?

Many thanks,

- Ian

View Entire Topic
Former Member
0 Kudos

We resolved this issue, we made two changes as follows;

  1. Recreated the JDBC Communication channel that was performing the lookup in the extended receiver determination
  2. One of the receiving interfaces was not assigned to the relevant receiving component, we also corrected this

Thanks for the suggestions.

Ian