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

Accepted Solutions (1)

Accepted Solutions (1)

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

Answers (3)

Answers (3)

former_member184154
Active Contributor
0 Kudos

Great job, Ian.

Had the same problem on a tricky synch SOAP2RFC scenario, and re-creating the RFC channel used in the Extended Receiver Determination actually did the trick!

Thanks for sharing.

Alex

Former Member
0 Kudos

Glad to have (indirectly) helped!

Harish
Active Contributor
0 Kudos

Hi Ian,

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).

-->> Are you using JDBC standard function, if yes then please check the parameterized mapping and binding.

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.

--> Can you please provide more details, why the error is in ECC? are you expecting ALEUD IDOC?

regards,

Harish

Former Member
0 Kudos

-->> Are you using JDBC standard function, if yes then please check the parameterized mapping and binding.


Yes we are, the parameter and binding is in place - we have used the OM/MM in a standard interface to test it at runtime, and we have tested via the test tool in the ESR. The mapping works there, just not when we need it to!


--> Can you please provide more details, why the error is in ECC? are you expecting ALEUD IDOC?


The error I have provided comes from PI itself, we can see it in the trace (we have been using XPI_Inspector to try and find a root cause). It seems that because the failure is before a receiver is determined that the message does not appear in the message monitor and that a failure is recorded in ECC, However when we interrogate the logs we can see the message arriving and the mapping being called - we were even able to extract the IDOC-XML from the logs!


We are using ALEAUD, but we're not getting to that point yet.

Former Member
0 Kudos

Hi

Please make sure that the parameters name provided correctly in the ICO. I mean there is no typo error in the name.

Former Member
0 Kudos

Hi Indrajit,

I've double checked the parameter names - but they are identical.

Ian

former_member184720
Active Contributor
0 Kudos

Hi Ian -

If i understand - Extended receiver determination is not working..?

Did you add your receiver systems under Possible Receivers?

Former Member
0 Kudos

Yes we are and yes the receivers are in place - the receivers mapping itself is failing.

former_member184720
Active Contributor
0 Kudos

Thanks for confirming..

I hope you have configured the parameters under receiver tab in your ICo Configuratiuon..

"GUIDGenerator.java:111 MappingAccessBean.java:527"for me it sounds like a program error. I would suggest you to raise an OSS message too when you are in the process of finding the root cause..