on 03-20-2014 7:32 PM
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
We resolved this issue, we made two changes as follows;
Thanks for the suggestions.
Ian
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
-->> 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.
Hi Ian -
If i understand - Extended receiver determination is not working..?
Did you add your receiver systems under Possible Receivers?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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..
User | Count |
---|---|
81 | |
25 | |
12 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.