I have a requirement which goes as follows:
We need to suspend the transactions of the trading partners whose status is suspended.for this we maintain a flag in our external DB for all the TN profiles.
The flow goes as follows:
1.check the suspended status(invokes an Adapter service which returns an isActive string depending on the status of the TP’s).
2.If suspended,i add a custom attribute(Suspended Trading Partner) to the bizdoc and resubmit it to TN,where it is picked by a processing rule with custom criteria set to “Suspended Trading Partner=true” and does nothing.
At a later point of time,when the Trading Partner’s status is changed to active in the DB,we want to resubmit the transaction.At this point of time,it is throwing duplicate transaction error as the same transaction has already been gone through the TN.
Duplicate checking is enabled in the pre-processing rules.
Can someone tell me how to get rid of this duplicate error when the transaction is resubmitted?
there was an EDI document already submitted to TN and now i want to resubmit that document again to TN and want the TN to treat it as a new submission.the flow is:
1.createDocumentQuery
2.documentQuery
(both of the above to get the document already submitted to TN)
Loop over results and got the DocID and got the content of the previous document.
Now that i have the content of the previous doc,i want to submit the doc to TN again and want TN to process it as a new document.
i tried all services(resubmit,receive,submit,reroute etc…)nothing is working…
Can the wM gurus out there help me out in this?
As you probably know, duplicate checking uses one of the following settings to detect a duplicate:
Document ID only
Document ID and sender
Document ID, sender and receiver
Document ID, sender and document type
Thus, on resbumssion one or more of these items must be different from the original. Or you must turn off duplicate checking (which I would advise).
Another approach that might work for your “suspended partner” approach.
Instead of resubmitting, reprocess. This causes TN to reevaluate the which rule should be invoked and does so. You can either have one of your existing rules/services or a new one that selects “Suspended == true” to do the suspended check and modify the custom attribute. If the attribute changes, reprocess the doc one last time to get it to go through the “normal” processing rule. This will avoid duplicates and reflect what you’re really trying to do–hold a doc for later.
As before, I still advise against doing any of this. You’re going to constantly run into issues and scenarios and you’re having the integration layer do work that more appropriately belongs in the application. IMO, you’re travelling down the wrong path.
Thanks for your time.
“If the attribute changes, reprocess the doc one last time to get it to go through the “normal” processing rule.”
Should i have to call wm.b2b.editn.util.reprocess:reprocessDocument to reprocess the Doc.but the input for this is the internalId of the doc.my doubt is if i modify the custom attribute,will it reflect and change the attribute as we are using internalId as the input and not the bizdoc.
I would really appreciate if we can discuss about how to implement it in the application layer.
Call wm.tn.doc:setAttribute to set the attribute. Then call wm.tn.doc:updateAttributes to save the changes to the DB. Then you can call wm.b2b.editn.util.reprocess:reprocessDocument or wm.tn:reroute to reprocess and the new attribute will be picked up. You’ll need to manage your pipeline variables carefully to make sure there aren’t any conflicts–for example make sure there is not a variable named bizdoc in the pipeline when calling reprocessDocument or reroute. Easiest thing to do would be to call one of those using the scope facility to restrict the pipeline visibility.
I’ve dropped the bizdoc variable before calling reprocessDocument.but still it throws the following error:
An error occurred while tracing.
com.wm.app.b2b.server.ServiceException: com.wm.app.tn.doc.BizDocTypeException: Cannot reprocess document 56q53b000n2i35fb0000015u.
java.lang.Exception: Fail to lock - no row exists for TN document ID: 56q53b000n2i35fb0000015u… [EDIFTN.000010.000258].
The flow for reprocessing goes as follows:
1.createDocumentQuery
2.documentQuery
3.loop over results
4.wm.tn.doc:view
5.setAttribute
6.updateAttribute
7.reprocessDocument
One more thing i observe is when i run this reprocessing service(custom service),when i set,update the attribute and reroute it,there is no EDITN Envelope in the pipeline.Although it is picking up the normal processing rule after checking for the suspended status,there is no EDITN Envelope in the pipeline.
Try wm.tn:reroute instead of reprocessDocument. I don’t believe you should need the functionality of reprocessDocument, which is primarily the deenveloping/split capability which raises the issue of duplicates again.
You’re correct that none of the “pipeline litter” that TN and EDI for TN leave in the pipeline will exist on a reprocess. Your services should never rely on anything being in the pipeline other than what wm.tn:receive/submit/reroute indicate will be there (bizdoc, sender, receiver, TN_params).
Were you able to get bizdocToRecord to work properly? Based on your previous posts I think you may be doing far more work than you have to to translate transaction sets and may have an unhealthy dependence on access to envelope data and delimiters. Of course my perception may be off since I don’t have the same level of info & detail of the design constraints that you do.
I use the data from the editn_env variable for the normal processing.i dont see that variable when i reroute it.i think i will have to find another way or may be i have to change the flow service all over to remove the dependencies on editn_env variable.bizdocToRecord svc is working and i can get the delimiters from it and also from the envelopeProcess service(Values variable).
Can you tell me one more thing.is there any service to get the EDITN Envelope so that i dont have to change my flow service all over again because i know that is a tedious job right now.
Rob,
Can you tell me one more thing.let’s say if we dont worry about the duplicate processing now(let’s say it is disabled now).how can i resubmit a doc if i have the raw edi string.when i use wm.tn.doc:resubmit, it is throwing error(some templateMgr error).
I do not know of a way to recreate the editn_env variable in the pipeline. It’s a by-product of the edistream content handler, I believe.
If you have the raw edi string, put it into a variable named edidata and call wm.tn:receive or wm.tn.doc.xml:routeXml. I don’t know why resubmit would throw that particular error.
Thanks a ton…that helped…now i’ve to think about how to handle duplicate documents.
Can you tell me how to implement this kind of behaviour in the application layer?
i think i’m bugging you up too much.i would really appreciate if you can let me know the high level architecture involved in implementing this.
Current application does it’s thing, managing customers and such. From your description of its behavior it can place customers in a “suspended” state for different reasons, including payment deliquency.
New documents coming in, being processed by TN/IS, would always be translated and forwarded to the application. The integration layer would have no concept of a “suspended” partner. The only time TN would hold a document is if the application cannot be communicated with for some reason (network outage, app down, etc.).
The application could do many different things to manage incoming documents for suspended partners. One would be to import/process the document and mark the item in some way. For example, an incoming PO could be put into an “Held” status. The application could have screens that users could review to see all the held items. That way when the partner calls in to find out what’s going on, the user could say “Yes, I see your order for 150 widgets. It’s being held because your account is <reason>.”
Holding documents in the integration layer makes such a scenario much more difficult to deal with.
If the application can’t support the facilities described above and documents must be held, then the application support team should devise an import/holding bin scheme that they can support. The integration layer’s job is to deliver the package. If the app doesn’t want to open it yet, then it should have a scheme for holding it, not TN/IS.
Thanks for your suggestions and i appreciate that.
Right now there is no application which can deal with these kind of issues.We pick up the documents from the directories assigned on per customer basis.This is how the system is designed now and they dont want any more changes to be done.i have suggested to them about the issues which can come up at later point of time if the integration layer does the work of application layer, but they just dont want to change the design.
i thought of a solution for the handling duplicate documents.give your suggestions on this.
whenever a Trading Partner is suspended, i set a custom attribute and call rerouteBizdoc, which picks up another processing rule with custom criteria set to “Suspended Trading Partner= true”.there will be a flag in our external DB (let’s say wasSuspended with all the info such as senderId,receiverId,DocCtrlNumber,GroupCtrlNumber etc so that a transaction can be identified in a unique way),which i set it to true by calling an Adapter service in the suspended trading partner processing rule.
what we do in the normal processing is,whenever TN throws a duplicate error(which will be in the bizdoc),we log it to the external DB for later use.our design is in such a way that we never depend on the TN database, we always log each and every thing in the external DB.
my approach is whenever i check for duplicate error in bizdoc,i will always check for the wasSuspended flag.if it is true i’ll not treat it as duplicate and continue processing.if wasSuspended is false,i’ll treat it as a duplicate and suspend the processing.
It is working.
Thanks a lot for your valuable suggestions.
I know that integration layer is handling too much of work, but cant help it because of the design considerations.