The problem of SAP (adapter 4.6) IDocs being logged to the IntegrationServer/packages/WmPartners/pub/mailbox directory seems to cause webMethods Integration Server administrators quite a few headaches. The standard supported mechanism to delete these files
is to call "wm.PartnerMgr.xtn.Sweeper:sweepTRX" service periodically to purge old transactions. While this is an acceptable solution, more than one administrator has asked how to disable this transaction logging altogether.

Information regarding this method can be found by combining specific information in the Partner Manager user’s guide with information from the SAP Adapter user’s guide.

STEP 1: Create a service to handle “content-based routing”. Name this service whatever you like, and put it somewhere where you put “common” services for server administration.

STEP 2: On the “Input / Output” tab, select the specification reference at “pub.sap.idoc.routing:inboundDefault”.

Step 3: Create a map step

Step 4: Add a string variable “$routeOnly” and set the value to “true”
By inserting the parameter “$routeOnly” with the value “true” prior to calling WmPartners, logging to disk is bypassed.

Step 5: Map “sender”, “receiver” and “msgType” from IDOC_CONTROL as follows (you will have to create the variables on the left under IDOC_CONTROL): (Note that this step is necessary if you use IDocs that are a version earlier than 4.0)

SNDPRN => sender
RCVPRN => receiver
MESTYP => msgType

On each of these three maps, edit the “Indices” to use “IDOC_CONTROL” index “0”, and insert a “Copy condition” ensuring that the variable being copied is not null (the following image is an example):

Step 6: Repeat step 5, only for IDOC_CONTROL_REC_40.

Steps 5 and 6 emulate the default behavior of the SAP adapter by extracting sender, receiver, and message type from the EDIDC

Step 7: Register this service with SAP adapter routing:

Call the built-in service “pub.sap.idoc.routing:registerService” with the parameters:

msgType => $default
service => {your service name}
inbound => true

After the sender, receiver, and message type are extracted, the IDoc is sent to the partner manager. These parameters are used to match a partner manager routing rule to determine where to route the IDoc. This service is automatically registered when the package is loaded.

The service you create is automatically enabled, and will be applied to all incoming IDocs. It can be disabled or unregistered as follows:

[SIZE=2]** TO DISABLE THIS SERVICE (AND ENABLE LOGGING) **
(NOTE: This service is intentionally disabled in development)

1. Open IS Administrative console
2. Open the SAP adapter configuration
3. Under “Default handling for all IDocs” change the “Inbound service” setting from “{your service name}” to “$none”.[/size]

[SIZE=2]** TO UNREGISTER THIS SERVICE **
Call the built-in service “pub.sap.idoc.routing:unregisterService” with the parameters:

msgType => $default
service => {your service name}
inbound => true

I hope that this guide helps others as a reference to address this issue in the future![/size]

– Christopher Kovacs

Most excellent description. Thanks for the tip!

Great post - did not know you could do it at the transaction level…

If you want to have the logging disabled for all IDOCs, you can simply set the following in server.cnf (or extended settings):

watt.PartnerMgr.noMsgStorage=true
watt.PartnerMgr.routeOnly=false

Using the above combination of settings still allows you to see the status of the transactions (via Routing | Transactions), but without the overhead of logging the entire IDOC content.

Setting routeOnly to true will eliminate all logging for all IDOC’s (and I believe that the noMsgStorage parameter is irrelevant at that point, but I’ve never tried it).

These settings are available if you are running in IS 6.1 or higher by default - if in 6.0.1 or earlier, there is a “performance fix” for WmPartners that needs to be installed - don’t recall the specific number.

I’ve read the “Performance fix” notes, but I did not see “watt.PartnerMgr.noMsgStorage” and “watt.PartnerMgr.routeOnly” documented in the SAP adapter user’s guide. Now that you’ve brought these to my attention (Thank you!) I see that Advantage artice id “1611969142” mentions this (Ref [URL=“https://advantage.webmethods.com/advantage?targChanId=kb_home&oid=1611969142”]https://advantage.webmethods.com/advantage?targChanId=kb_home&oid=1611969142[/URL] ).

My proposal allows you to enable / disable IDoc logging on the fly or on a transaction filtering level, but I agree that it is not the best solution for globally disabling this feature.

Thank you for your feedback. This will be very helpful!

– Christopher Kovacs

Hi Christopher Kovacs,
Thanks a lot. The best explanation ever I have seen so far.

Thanks
Ram

Hello,
When set the “watt.PartnerMgr.noMsgStorage=true” and “watt.PartnerMgr.routeOnly=false”, will it still writes entries to the files “xtn.log”,“xtn_audit.log”,“xtn_store.mdb” and “server*.log”?
We had met the situation of the size of “server*.log” for one day is overy 30GB when there are many Idoc transactions, so we had to unselect the Logging Facilities “0073 WmPartners Gateway Manager” to reduce the log file size. Thanks a lot!

Hi,
I have a question regarding this. I would like to get some expert opinion and inputs.

What is this logging used for exactly? Will it be of any help when debugging issues? Or is this just redundant information, stored else where too(in Sap or Service audit logging). I am really interested to know what exactly are we losing if we can turn this off completely.

I am currently looking for the good option between, turning it off OR scheduling wm.PartnerMgr.xtn.Sweeper:sweepTRX to clean it.

It can help with debugging. If you turn off completely, then you pretty much lose visiblity to what is happening with the IDOC’s. I always like to set noMsgStorage to “true” and routeOnly to “false”. This combination allows you to see the status of transactions, but does not log the content of the IDOC. With this combination of settings, you still need to run the sweepTRX service to clean up the transaction entries, there’s just no IDOC stored - which is what puts the highest i/o demand on the system… It really all depends on what level of visibility you want to have. Also bear in mind that I’m referring to the 4.6 version of the SAP Adapter. I’ve not had the opportunity to use the 6.x version of the adapter, so I’m not sure how that one behaves and if any of this is still relevant…

My recommendation is to test it out and see what works best for you…

Hi - Thanks a lot for the quick reply.

I personally like to have high quality of service at the cost of a reasonable performance hit.

But, somehow i never used the Sap transaction logging in the Integration Server to debug issues. I always, either check the service status in the IS(if logged), or the IDOC status in Sap itself. Can you come up with a couple of scenarios where the information in this log becomes useful for debugging? I only have a little experience with this, so i can’t think of any.