I’ve had enough troubles working with Modeler/Monitor/PRT in the past. I am concerned with the performance overhead these components bring to the integrations. I see a point using PRT where there is no TN so that it can be reprocessed in error situations. However I am contemplating if I should use PRT for RosettaNet implementation. We got TN anyway. I know wM recommended approach is to go PRT way.
Alternate approach I am thinking is to implement RNet on top of TN/RosettaNet internal services. After all RosettaNet is MIME message exchange over internet in RNet recommended order. Any reprocessing/resubmission can be achieved thru TN. I dont know if I am missing obvious things here. Wondering if anyone implemented RNet in v6 eliminating PRT. Comments are very much appreciated
I am not sure we could implement RosettaNet without PRT. Most of the RosettaNet implementations want to take the advantage of Modeler and monitor. I understand the fact that PRT would have performance overhead. I would consider tuning integrations and a well defined architecture using PRT rather than taking a new approach and running into more issues.
With new IS6.x architecture doing RNet integrations the Modeler/WmPRT component is mandatory and this is the standard way of processing and eliminated TN Conversation Manager which is in IS4.x.
Unlike EDI, RosettaNet PIPs involve Processes (or conversation between Trading Partners). There are multiple documents exchanged per transaction (4 if everything goes well, 16 for the worst case) which needs to be tracked. Add to that you have an allotted time (TimeToPerform) where everything has to complete. No, that’s close to impossible to handle w/o PRT. So even if the PRT components are optional, I don’t see how anyone in their right might would want to try…:lol:
Actually, most EDI processes could readily be modeled just like RN PIPs, with the models waiting for additional documents and so on. The issue is 1) the processes generally vary in every implementation (the value of RN is that it defines processes, not simply data formats); 2) wM doesn’t provide sample models or even suggest to do things this way.
It’s not impossible (nor close to impossible) to do RN without PRT but I agree that it would be somewhat silly to try to reinvent what’s already working.
Agreed. But it does make things extremely complicated for newcomers. You’d have standard processing, non-standard processing, standard processing with Models, and non-standard processing with Models… The technical writer would need to take extra-strength Tylenol too…
Using TN, store in/out docs with appropriate attributes that can be used the retrieve document(s) later. When subsequent docs arrive in TN, extract the appropriate conversation/correlation IDs to retrieve related document(s). Process as appropriate.
How would you handle Time-To-Perform (in Two-Action PIPs) w/o PRT? An expiring AND join?
Come to think of it, that’s probably how the RN models are implemented too. Tracking the progress of the RN conversations would need to be custom too, since you can’t use WmMonitor. Wow, almost like a throw-back to the RN 1.6 days…