We are working on wM 7.0 Desginer and are having problems in correlating TN document types.
Below are the steps followed by us:
Build up the BPM using designer. The BPM has one broker receive step with a correlation service which invokes the BIS pub.prt.lookupcorrelation service with mapping type set to TN.
Sent the doc to TN using the wm.tn.receive service. A processing service invoked sends a response document back to the TN (using another wm.tn.receive service). (Note: Complete model on a single IS).
For the response Doc Type in the TN, conversation ID is extracted which is same as the correlation ID set in step 1.
The only processing action attached is a change user status action to DONE.
At this pt, we expect the PRT to internally correlate the response doc with the TN receive step (receive step subscribing to TN doc in the model).
However, this is not happening and we are getting the following error:
com.wm.app.b2b.server.ServiceException: [PRT.0101.9125] Service pub.prt.tn:handleBizDoc failed
This error occurs at the wm.tn.receive service invoked through the processing action service invoked at the end of step 2.
Does someone know if we have missed something out here?
Is there any other way in which correlation is established through TN docs?
Also, lookupcorrelation seems to be establishing the correlation mappings and creates entries in the WMPRTXREF table; so what is the use of the establishcorrelation service?
I may be off-base here, but I don’t think you need to do any of this submission to TN and correlation handling within the model yourself. What do the docs say about how to set up this sort of request/reply type of model?
From what you describe in your use of PRT and TN with correlation IDs its not clear what actual components are involved. So here are my only guesses:
In your description you are using TN and PRT and TN receive step usee as PRT step?
First of all corelation IDs are critical to processes wich have some Join step/s! But in your description you not mention anything about join steps or any details about your model?
It seem you are trying to corelate incoming TN document with existing PRT process that is waiting for it in a Join step? That is possible case where you would use correlation even though not described in your case. To my knowledge the only TN module that does this in WM is RosettaNet. But you not mention it so I assume you trying to make some custom TN process work with PRT.
If you are trying to tie custom process to TN then you probably missing the corelation creation step. If you are not doing it you may have to call pub.prt.correlate.establishCorrelation service for your start process part.
When you pub a document and start process it creates Proc ID and default corelation ID for you and place it iether in RAM or DB depending on PRT configs. Your custom TN process step is looking for TN converstionID when infact your process started and probably logged it as IS correlation ID. So you are not finding it as TN correlation.
I recomend iether to try using consistently IS correlation in your step or perhaps making custom corelation service that can match your PRT starting corelation ID and TN conversation IDs adn join the process.
You are right in your assumption that we are using a custom BPM with a join step waiting for the TN document (AND join in our case).
On your pt about correlation and conversation IDs, we have tried to use conversation ID all throught the process. This has been achieved as mentioened below:
The first receive step (subscribing to the broker) in the BPM uses a correlation service which maps the Proc ID with the Conversation ID. (This is done by using the lookupcorrelation service with mappingType set to TN). We hope that this is all that is required to overcome the problem wrt converstation/correlation IDs)
The second receive step (subscribing to the TN doc) has a correlation service which tries to map the conversation ID coming from the response document with the entry in the WMPRTXREF table so that the correct process instance is joined. (However we feel that this step is redundant and the extraction of the conversationID from the incoming doc in the TN should automatically lead to correlation and hence the joining with the process instance)
Attached for your reference is the jpeg of the BPM.
We are facing the same issue whenever we try to assign a custom developed service as a correlation service in the process model. Could you please elaborate as to how this was achieved earlier?
We are facing the same issue whenever we try to assign a custom developed service as a correlation service in the process model. Could you please elaborate as to how this was achieved earlier?
