wm.tn.doc:recognize

, ,
1

Has anybody experienced performance issues with wm.tn.doc:recognize which is the first step in wm.tn:receive? I have noticed this for certain EDI transactions and was wondering if anybody else has noticed the same.

I have opened an SR with webMethods but no leads as yet.

2

We are using this service in our framework with a huge number of documents flowing in and out on daily basis. As of now we didn’t encounter any performance issues. Can you share some of your observations please?

Cheers
Guna

3

Hi Mathew,

Have you got the SR update from webMethods? If so can you pls share it with us?

4

I have not received any feedback yet. Are you facing the same problem?

5

I think de-enveloping occurs during recognize. If you have a lot of transaction sets (or large sets) in an envelope that might explain the apparent delay?

6

I took a stack trace while running the service and found that the thread was hung at at wm/b2b/editn/db/FADBops.queryDocIds(Bytecode PC:50(Compiled Code))
Reporting to wM was told this is due to bad join in SQL which is fixed in EDIforTN_6-5-2_Fix7. I am getting ready to get this fix in and see where it goes. Hope this helps the others facing similar issues.

7

We are having same issue even after applying EDIforTN_6-5-2_Fix14 and pre-requistes. Did this issue ever got resolved after applying EDIforTN_6-5-2_Fix7?

Cheers,
Akshith

8

I am yet to put the fix in prod where the performance issue seems to manifest (Due to data volume). Here is what i recommend:

  1. While the service is running take a stack trace.
  2. Analyze the stack trace for the running thread. If the delay is still at the Oracle query, run a trace on the database side and capture the SQL being executed. Get an execution plan on the query and get with webMethods on it.

I intend on doing this after I get the fix in Thursday!! HTH.

9

Thanks for the reply, We already opened a log with SAG support but just was curious if this fix resolved the issue for you. Did this issue resolve at least in your QA env? if it does then we will also plan to roll back to the old fix EDIforTN_6-5-2_Fix7 and its prereqs.

Cheers,
Akshith

10

Here is what I found. I installed Fix9. The jar file that fixes the issue was packaged incorrectly and placed in /packages/WmTN/code/jar directory. The correct place is /packages/WmTN/code/jars. I installed Fix15 which has it right and is cumulative. This resolved the issue.

The original bad query was:

SELECT editracking.docid, editracking.fastatus
FROM editracking, bizdoc
WHERE editracking.senderid = ‘m1gcfk0v068uhu6b000000ip’
AND editracking.receiverid = ‘m1hkke00vda1u0m500000043’
AND editracking.groupid = ‘1’
AND editracking.grouptype = ‘SH’
AND editracking.groupversion = ‘4010’
AND (bizdoc.docid = editracking.docid OR editracking.docid LIKE ‘EDI_%’)

It has been changed as below:
[FONT=Arial][COLOR=#0000ff]

SELECT editracking.docid, editracking.fastatus
FROM editracking, bizdoc
WHERE editracking.senderid = ‘m1gcfk0v068uhu6b000000ip’
AND editracking.receiverid = ‘m1hkke00vda1u0m500000043’
AND editracking.groupid = ‘1’
AND editracking.grouptype = ‘SH’
AND editracking.groupversion = ‘4010’
AND (editracking.docid LIKE ‘EDI_%’ or Exists (select 1 from bizdoc where bizdoc.docid = editracking.docid))

[/COLOR][/FONT]

11

nMathew,

What’s the IS/TN version you have running on?

HTH,
RMg

12

Is 6.5 sp2
tn 6.5