We have a document coming in from the partner over https to wm.ip.rn:receive (this document is a part of a RosettaNet conversation, which is why its coming to rn:receive, instead of tn:receive). All we wanna do when this document comes in, is to use a processing rule to invoke a service. The problem is, when the document is posted to wm.ip.rn:receive, it shows up in TN alright (document type, sender, receiver identified properly), but, the service (set up in the processing rule to be invoked sych) does not kick off. After I failed a few times to invoke the service, I decided to post the same document using wm.tn:receive and voila… the document was identified and service was invoked - which confirms that processing rule is setup right.
Looking at the code of rn:receive, the service sends the document to TN using wm.tn.doc: presist - is this not supposed to invoke the processing rule? Is there a way to invoke a processing rule when the document is coming through rn:receive?
Note: We do have process models setup for various document coming in thru rn:receive, but, for this particular document, we do not want to set up a process model, as the processing required for this document is minimal and it does not require monitoring.
The persist service does not do anything more than save the document. Once it is saved, you can cause the processing rule to kick in though I’m not quite sure which service you need to use (routeBizDoc?).
Thanks for your reply… If ‘persist’ does not kick off the processing rule, I wouldn’t be able to achieve what I was trying to do. My scenario is that the document sent by TP is received by rn:receive (which uses persist) - I was wondering if there was a way to kick off the processing rule when the rn:receive receives the document (just like when tn:receive gets the document, it kicks off the rule). Unless this happens, there will be no way for us to know that the document has arrived - except for creating a process model that subscribes to this incoming document. And that (creating a process model) is what we have been trying to avoid doing.
I can’t come to accept that rn:receive cannot kick off a processing rule [-(
I’ve never used the rn module so I’m not sure if this is doable but you might try…
Create a wrapper service that the partner posts to instead of rn:receive. This wrapper service would call rn:receive then use the resulting bizdoc (should be in the pipeline) to invoke the appropriate TN service.
rn leverages some of TN but the use of processing rules and conversations of TN was abandoned in favor of using Modeler and the PRT. So it’s not entirely surprising that you may need to do some extra work if you really do want to use TN for processing.
Is there some stuff that rn:receive does that you can’t live without? If rn:receive doesn’t add anything (like I said, I’ve not used rn so I may be way on all this) then you might consider using tn:receive instead.
Rob,
I understand that if the scenario allowed me to create a wrapper service and have the TPs invoke it instead of the rn:receive, I could have achieved what I am aiming at… in fact, then I wouldn’t need a processing rule, because, the recognition could have taken place within my wrapper service and I could have passed the bizdoc to my handler service that would process it. But I can’t have the TP send a specific step in a conversation to a different service than the service to which rest of the steps are coming. Uhmmm I think it all might have become very confusing without me having described the scenario completely - here it is.
We are doing RN Conversations with our TPs - eg, The TP sends us a RequestForQuote (RN Document) - RN requires this to be sent to rn:receive. Upon the receipt of this document, an appropriate process model is kicked off, which invokes a series of services in the process of sending receiptACK to the TP and finally responding to the TP and receiving their receiptACK. NOW - one step in these conversation could be ‘Notification of Failure’ (which is another RN PIP document - PIP0A1). Ideally when a TP sends a NoF, all the actions performed by the corresponding conversation should be rolled back, but we don’t want to do that (as yet), what we want to do is simply send out an email (to the stakeholders), with the contents of the document… the reason we wanna explore this option instead of creating a new process model for PIP0A1 is that we wanna avoid adding another process to the monitor, especially because we don’t really need any visibility into PIP0A1 more than what will be provided by an email.
So you see, the TPs already have rn:receive set as the destination in our profile on their TN, and because this is the standard way to go, deviating from it for a simple reason of avoiding another process model is not a good idea. I wanted to explore if it could be done without a process model - if it can’t then I would switch to a process model and have a step therein invoke the service that will send out the email. Thanks for your time n suggestions… if you find something that could work… that would greatly help, not only in my attempt to avoid a process model, but also to provide me some learning.
RMG,
The Activity Log just says that the document has been persisted… no rule is selected. As Rob pointed out… I think persist does not invoke the processing rule. I checked the rn:receive - the incoming document is recognized and then persisted, causing it to show up in the TN, without invoking a processing rule (not even the default rule).
Your concern about adding another model to monitor is somewhat understandable but that’s probably the way to go. Just crank down all the retry/logging stuff to nothing to minimize the impact to system.
“…already have rn:receive set …and because this is the standard way to go.”
This doesn’t help you at this point but perhaps it will benefit those that come upon this thread later–this is a classic example of why you don’t have partners invoke the webMethods supplied services directly. It limits your options when unique cases present themselves. Sonam Chauhan covers all the issues, in the context of TPs calling wm.tn:receive, with TPs doing this.
[url]wmusers.com
Some of the points are dated (e.g. TN can now returns an error, not success, if the document processing fails) but the many of them still hold true. Would recommend that you get your TPs away from invoking rn:receive directly and using a wrapper instead at a reasonable point in the future.
If you can find the document name as NOF in the rn recieve service, u can submit another doc(any temporary doc with the same set of inputs like conversation id) to TN and invoke a processing rule, so that u can send mail, with all the contents based on the conversation id.
tn.persist service recognises the doc first, so u can find the doc name and check for the doc name as NOF.
I agree with you… I had read Sonam’s article too… but I can’t change the way things happen. I have joined this org recently and wish that I could change a lot of processes and the way things have been designed, but they are so far down the road doing what they do and how they do it… that … phew!!! Also, there’re always more important things to do than to fix stuff to improve performance. I’ve tried reasoning in the past… but well… so I don’t think there’s a point suggesting a change in the receiving service, because this would require all our TPs to change their settings. I guess I’m gonna have to live with it for now and go ahead with creating a process model.
If you are using RN module ip.rn:receive subscribe the document to a processmodel is the standard approach in 6.x.Anyways customization of rn:receive is not a good idea at all.
Yes, I have resorted to a process model… we already have dozens of process models for different PIPs… since 0A1 is gonna serve us very little purpose and we don’t require monitoring on it… I was hoping to do without a process model.
Of course I am not going to change the rn:receive service… that is out of question.
