|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Slow processing of IDOCS in 03 Status by mySAP.com adapter |
« View previous topic :: View next topic » |
Author |
Message
|
smeunier |
Posted: Wed Dec 14, 2011 8:06 am Post subject: Slow processing of IDOCS in 03 Status by mySAP.com adapter |
|
|
 Partisan
Joined: 19 Aug 2002 Posts: 305 Location: Green Mountains of Vermont
|
I may have accidentally posted this twice, so if I did my apologies.
And interesting event has started to occur within our implementation of using the mySAP.com adapter, which occurs randomly and is not re-creatable.
Environment for Adapter process:
OS: AIX 5.5.0.0
SAP Adapter: V6.0.9
Framework: V2.6.0.11
Situation:
On random days and random times, the SAP queue of outbound IDOCS in status 03 come to a crawl for processing them through the adapter. Given hours, they may eventually all process. This problem has been happening more and more frequently lately and is starting to become a business issue, as data is not flowing down stream fast enough.
I'm not sure if the issue is adapter related or SAP related. At time recycling the adapter seems to resolve the situation, by rapidly processing the backlog, other times is has no affect. During this situation, IDOCS can be manually sent to the adapter and they process with no issue. This tells me, the adapter is listening for events and handling them.
In an attempt to remedy the unknown cause, we have increased the NumberOfListeners=5 and the MaxNumberOfConnections=10. Changing these setting have not resolve the issue. We are still dealing with slow processing.
There are no errors that show in the log or trc files for the adapter when this event occurs and doing an RFC trace is out of the question, because it is a production system, and it is unknown when the problem may occur to handle the size of logs produced.
The only solid evidence, is that when it does happen it is at the close of business (dump of transactions to SAP for outbound process) by one of our business partners. However, as I mentioned before, it is random, if it occurs at all. Under less time critical circumstances, a delay in processing is acceptable. Left on its own, it appears like it would resolve itself and eventually catch up, but this is not acceptable.
My question is, what setting(s) can be modified in the adapter configuration to perhaps open up the throttle of Outbound IDOC processing to the adapter? Does this appear to be a adapter issue, or more of a SAP issue? Has anyone seen this? Is there a better way to pinpoint/debug the culprit? I
An interesting note, is that Inbound processing does not seem to be affected.
During times of this problem, I have confirmed that data is flowing through the adapter, both inbound and outbound.
Any information or comments would be greatly appreciated. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Dec 14, 2011 8:20 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Have you looked at SAP being the culprit?
After the dump from the business partner are all the RFC processes in your SAP app servers being used and busy?
SAP allows you to configure the resources differently depending on time of day and type of load... Take advantage of it!  _________________ MQ & Broker admin |
|
Back to top |
|
 |
smeunier |
Posted: Tue Dec 20, 2011 7:24 am Post subject: |
|
|
 Partisan
Joined: 19 Aug 2002 Posts: 305 Location: Green Mountains of Vermont
|
It appears that at some point the adapter is getting choked (lack of better technical term). When the adapter recycles, the problem clears. I have debated as to whether this is because on the adapter side things are being cleared (memory) or if resources are being released in SAP, or both. On SAP there are plenty of RFC processes available during the slowdown. What I'm wondering, is if there is any way to trace what is coming through the adapter during a given point in time. Specifically, if there are any transaction metrics that can be gathered by enabling a switch or trace option?
It is possible, that by adjusting the PollQuantity (currently set at 20) that we could achieve more throughput. However, without a effective way of gathering data on a per transaction basis it would be difficult to determine the effectiveness of changing this value (or others). |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue Dec 20, 2011 8:51 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Have you tried scaling the flow? Is that acceptable or does the process suffer from message affinity?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|