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.
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).