SAP PO - Groovy mappings - java.lang.VerifyError

[Steven_UM]

Hi,

We have a SAP PO 7.5 dual usage system ( JAVA SAP 1.8.0_221 / VM Runtime version 8.1.059 10.0.2+000 ) and have been playing aroud with using Groovy in some of our java mappings.

We are currently having a bizarre issue with those groovy mappings that we cannot explain nor seem to find the exact cause. These issues prevent us from starting to use Groovy on a larger scale.

We have built several small groovy mappings and those work fine in all our environments - they do what they need to do. However, once the SAP PO JAVA system gets restarted then those mappings start to fail with the following exception:

java.lang.VerifyError: Stack map does not match the one at exception handler... 

Or in more detail ( with actual class names changed 😞

java.lang.VerifyError at JavaMapping.instantiate(): Could not instantiate class: com/xxxxRcvDetStack map does not match the one at exception handler 117 Exception Details: Location: com/xxxxRcvDet.transform(Lcom/sap/aii/mapping/api/TransformationInput;Lcom/sap/aii/mapping/api/TransformationOutput;)V @117: aload Reason: Type top (current frame, locals[0]) is not assignable to 'com/xxxxRcvDet' (stack map, locals[0]) Current Frame: bci: @95 flags: { } locals: { top, top, top, top, top, top, top, 'com/wily/introscope/agent/trace/IMethodTracer' } stack: { 'java/lang/Throwable' } 

It seems to be related to the Wily Introscope Bytes Agent adapter.

We already installed SAP note 2542663 which seems to refer to a similar alike issue but this did not help.

In order to 'fix' the issue we basically need to repeat the mapping transport cache notifications several times ( no fixed repeat - depends ) and at one point the issue is gone and the mapping executes.

We also observed that we always have this issue on our acceptance and production system but only rarely on our development system. All systems are in sync as far as settings and java versions - the only difference being that our dev system is a one node system.

We are currently using groovy v2 ( we started with that before our PO upgrade ) but already tried groovy v3 but it does not make a difference.

While trying to pin-point this issue and playing around with the v2/v3 groovy change we also noticed some overall strange behaviour in terms of groovy development and the above issue. One can almost guarantee the issue to occur on development - even during simple test of the operation mapping in the builder - when writing the code a bit differently.

Eg when writing the code using a try - catch with Exception then the issue occurs immediately upon execution:

public void transform(TransformationInput Input, TransformationOutput Output) throws StreamTransformationException {

try {
// Groovy coding ...
} catch(Exception e){

throw new StreamTransformationException(e.toString());

}
} 

Eg when writing the code using a try - catch with Throwable then the issue occurs further down in the code and seems to happen in a generated closure groovy class - the trace shows nicely that some groovy standard class are loaded first before the actual code line is reached:

public void transform(TransformationInput Input, TransformationOutput Output) throws StreamTransformationException {

try {
// Groovy coding ...
} catch(Throwable t){

throw new StreamTransformationException(t.toString());

}

} 

Eg when writing the code without a try - catch then the mapping executes successfully !

public void transform(TransformationInput Input, TransformationOutput Output) throws StreamTransformationException {

// Groovy coding ...

} 

This all seems very weird and makes no sense. We would love to use Groovy for a number of new mappings as this prepares us for a potential migration to CPI but for the moment we are hesistating as the whole setup seems buggy and not reliable due to the issues we face with the restarts and the potential pickyness of the code writing.

Anyone any feedback / ideas on what could be the cause of this ?

Thanks, Steven

[Steven_UM · Accepted solution]

For those interested .. we found the issue at last.

We had created a ticket with SAP support and they suggested to disable the Wily Agent on PO and test whether the mapping still had the same issues.

While examining the system for disabling the agent, our SAP BC team discovered that the PO Agent was on the latest version ( v10 ... ) while the actual configuration settings on the solution manager instance still indicated that the agent was version 8. Hence the agent was started with the wrong configuration settings on PO.

This apparently caused the strange issues we were encountering. After correcting the configuration settings the issue disappeared completely.