SAP Adapter 4.6 caching BAPI parameters

I’m using the SAP Adapter version 4.6 with SAP version 3.1H

I call a BAPI which expects an input parameter MATERIAL_TYPE.

If I pass an invalid material type, I get an NO_MATERIAL_RETURNED exception thrown from the SAP BAPI, which is correct.

If I pass a valid material type, I get the results returned for that material type, also correct.

But, now, if I make another call and pass an invalid material type, I get the same returned list of materials, i.e. NO EXCEPTION is thrown.

As soon as I make one valid call, IntegrationServer somehow is caching the good parameters and passing then each time I call the BAPI. Monitoring the pipeline in Developer verifies that the correct material type parameter I enter is being passed into the outBound map step for the BAPI.

Once this has happened, I can no longer generate the error condition. The only solution is to restart IntegrationServer.

I’ve gone and cleared the DDIC-cache but it doesn’t help. I’ve also ensured I drop all parameters from the pipeline in my flows after I am done.

Any suggestions?

Matt,

You might want to check your runtime parameters under the “Settings” Tab(in Integrator) for your outbound BAPI map. There is a caching setting there which may have been turned on.

The DDIC should not have affected this since from what I have read, the DDIC cache only holds on to the structure of import/export parameters and not the actual contents. Does anyone know for sure?

Well, I hope this helps…

Andrew

Andrew:

Thank you for taking the time to provide some input.

After looking at the cache settings for the outbound map, none were set (i.e. the cache checkbox was unchecked) which I assume to mean no caching (the default).

What about the “stateless” option? Should this matter?

Don’t these settings only apply to the map when run via Developer?

I should provide some more information, I am calling the map service from a Java Service because I need to “wrap” the call in some way in order to capture the exceptions thrown (if any) from the SAP BAPI. I got this technique from the WmSamples package. Is this how you capture exceptions from SAP BAPIs calls? Maybe I should make this “wrapper” service stateless, and it is caching the params somehow. After all, it is the one putting the paramters on the pipeline for the service inputs. Although as I said in the original thread, I have verified that the parameter values are correct up until they are passed to the map.

Thanks.

Matt

Matt,

Did you check you Java Service cache settings too? Make sure those are not set too.

As for the “Stateless” option… check out the Developer guide under “Specifying Run-Time Parameters” for a pretty good explaination on what that does. There are some implications on session objects to Java services that you need to be aware of and it is mentioned there.

As for run-time settings in general, once they are set, my understanding is that they are in-effect outside of the developer environment too.

I use a combination of built-in services & Flow steps(Branch, Sequence, Exit) to trap errors.

Does anyone have a better idea on handling flow errors, esp flow step timeouts?

Andrew

As it turns out, all my searching in WM was for not, there was a programmatic error in the ABAP program driving the BAPI. The ABAP program needed to reset the input parameters for each call, but instead created a list of parameters and would cycle through the list elements each time I called the BAPI, unless I disconnected from SAP and created a new session (which was accomplished by re-booting the Integration Server, which incorrectly implied to me that the problem was a IS caching problem).

I guess you learn something new everyday.

Thanks for the input.