Hi

I would like to invoke a business model without the need of having to first publish a document to the broker that my model subscribes to.

How do I do this?

Thanks,
dezer

Hi Dezer

I am not sure whether you could start a business process without having a subscribing doument , as the Modeler basic concept is the process is triggered of with a publishable document

Cheers
Jeevan

Hi,

Well I could publish localy to avoid going via the Broker, but it would be nice to be able to avoid the publishing completely. But as far as I understnad this might not be possible.

Thanks againg Jeevan =)
/dezer

If not using a publishable document type, how were you planning on kicking off your process model?

Let’s say you want to initiate your business process when some event occurs. That event will most likely be represented by a row being inserted in a database table, a JMS messaga arriving in a queue, an http post being received by some server, a web service request or a candle buring through a string.

With the exception of the candle and string all of the other technical events can be used to invoke a Flow or java service which in turn publishes the document that will initiate your business process.

What is it that you think you can’t do here?

Mark

I think that’s the crux of the question–how can one kick off a model without publishing a document?

I’ve encountered scenarios where it would be convenient to kick off a model without publishing a document (probably a faux document at that). The choice to start a model based solely on the arrival of a subscribed document would seem to be a hold-over from when what is now Modeler was a distinct application (a non-wM one) that was meant to support multiple types of message brokers. IMO, there really is no need to continue this relatively arbitrary restriction.

I know of at least one fairly large company that tried to kick off models without publishing a doc but there were more headaches than benefits and they never got it to work quite right.

It’s probably best at this point to just pub a document, otherwise you’ll introduce maintenance issues as those that come after try to figure out why it’s being done in an “odd” way.

Let’s assume that a process model must be initiated by some technical representation that a business event has occured and optionally some basic data about that business event.

Without turning the first step of a process model into some kind of generic listener which looks a lot like IS, what finite set of technical representations would you think is reasonable for Modeler to use to initiate a process model? How are those representations superior to a document published to Broker? BTW, you can’t cite not having to buy Broker as an advantage since you need it for PRT.

Mark

The advantage: you don’t have to buy Broker.

Publishing a document is but one way to announce to the world that something happened. Pub/sub is very cool in many ways, but it’s not the only way to do things. As you well know, my position on Broker is that it’s not needed in the vast majority of business integrations. We’ve debated the merits of pub/sub in the past and can do so again.

Broker is not needed for PRT, though the docs lead one to believe otherwise. While the PRT needs Broker to “jump” from one IS instance to another (assuming one implements multiple logical servers), it’s perfectly content with local publish. I just verified on my local machine that PRT will indeed run just fine without a configured Broker. Kinda spiffy.

To explore that a bit further, there are settings for PRT that make Broker all but superfluous even when it is present. If all the steps in a model use the same logical server (indeed, I’ve seen installations where all steps in all models use the same logical server–the default logical server) and “Optimize Locally” is enabled for the model, then Broker is not used at all except possibly for the subscribing trigger.

The PRT would just need to expose the service that sets up the run-time environment–a “wm.prt:startModel” if you will. The inputs might be the model name and any parameters the model might need. Yes, it’s a point-to-point mechanism but in some cases, that would fit the need nicely.

I can’t imagine that an IS-only PRT would scale as well as one that incorporated broker, but perhaps that’s just as much of a myth as System.gc() actually helping with performance. :lol:

Have you seen any performance benchmarks comparing IS-only pub/sub to Broker pub/sub?

But back to my original question. What else would you use to kick off a process model beside an IS invoke? Seems like exposing a new service to PRT to kick off a model is about the same work as publishing a document.

Mark

I’m never going to hear the end of System.gc() am I?

I agree that the throughput of IS publishing is most likely not on par with Broker. For environments that need high volume message publishing, Broker is definitely the way to go. But not all installations need high volume messaging.

I agree also that if the PRT exposed a service, then calling it really is no different than calling pub.publish:publish.

However, one needs to define a document type to publish. This document type is probably in addition to the “real” document since pushing/receiving a publishable document exposes the Broker env structure, which is generally undesirable.

Consider an “adapter.” Not an ART-based component, but a logical adapter the sole purpose of which is to interact with a resource of some sort and the integration layer. This adapter needs to do some work, accepting a document via an http post or reading data from a DB or some other data gathering step, then tranform it to a common format and then finally publish it to the world (via Broker or through TN or whatever).

It may be useful to track the work this adapter does, perhaps even model its logic. Using PRT in this scenario might be appropriate as it can log the adapter’s activities and progress. To start the model, with the way things are now, the entry point of the adapter needs to publish a document–essentially to itself. This “go” document wouldn’t be of any interest to any other component as the document is most likely application/adapter specific. It is the final document (the canonical document) that the adapter produces that’s of interest.

It would seem in this case that publishing a “go” document is unnecessary. Invoking a service to kick off the model, since the model and the entry service of the adapter are tightly coupled anyway, would seem to be a preferrable approach.

That said, the notion of publishing an application-specific document to which a transformation agent subscribes, transforms and then publishes as a canonical document type has been around for a long, long time. It’s certainly a viable model, and very flexible, though relatively complex in the scheme of things.

TN is able to kick off models without publishing a document. Perhaps the knowledge of how TN accomplishes that would provide an approach that dezer can use.

Hi,

The thing is that I do not want to re-invent the weel here. I don’t really have a problem with usign a published start document, but it would be nice to have th option not to. As I see it the way to go here is to use the publishable dokument to kick start the model.

Thanks for all the input.
dezer

Forgot to mention that when a model has “Optimize Locally” enabled, there is no publish whatsoever. Step transitions are managed via direct service invocations. Page 60 in the Modeler User’s Guide for 6.1.5.

To summarize:

• Optimize Locally enabled–no publishing, regardless of Broker presence

• Optimize Locally disabled–publishing, local IS publish if Broker not present, Broker publish if Broker configured

dezer–I think that’s the right way to go. Perhaps at some point wM will provide an option to initiate a model via other methods.

Rob,

Good catch on the “optimize locally” settings. That’s really interesting for those environments that don’t have ultra-high volumes through their process models.

I bet if we dug around enough we could figure out how TN is initiating models without broker docs. If the services were in the TN package that would not help those who did not use TN, but if said services were contained in the WmPRT package…

Mark

Hi Guys,

We are using PRT to trace our application. The design is an external application invokes a IS service which in turn invokes a PRT model (Model1) by publishing (request / reply) a document (DOC1) to the broker. Then Model 1 invokes another model (Model 2) by publishing (request / reply) another document (DOC2) to the broker.

The problem is performance. For business reasons we have implemented it as above but now the total time taken is exceding our SLA. If I make the second publish (Model 1 to Model 2) a local publish the time taken is reduced by 3 - 4 seconds. Which means for some reason the second PRT model is not getting invoked for immediatly, its taking some time (3 - 4 secs) before starting the first step.

My questions are:

1. Why is there a huge difference (3 - 4 Sec) between local publish and broker publish (Considering the fact that both IS and Broker on the same machine).
2. What should I expect in a clustered env if I make DOC2 a local publish.
3. Can I tune anything to make the document retrival fast.
4. Why is my Model1 getting invoked quickly.

Any help is much appriciated.

Ram Challuri

We’ve been struggling with this for a month or so now, strictly following the procedures outlined in the Modeler 6.5.1 Users Guide, on page 124. So far, we have been unable to accomplish it. So we’ve fallen back to our original approach of manifesting the web service as a flow service which in turn pubs a document to trigger the model. This of course brings with it the limitation that you cannot send back an asynchronous resultant from the model to the caller. So far, that hasn’t been an issue.

Keith: Were there any specific errors you encountered? Maybe those will provide some hints to someone. Clearly there has to be a way to do this since TN pulls it off just fine.

Analyzing the wM java code shows that the TN method finally also publishes a document to the PRT to trigger the start of the model instance.

The published document in that case is “wm.prt.status:CorrelationUpdateVol” or “wm.prt.status:CorrelationUpdate”, depending :

• whether the model is identified upfront (when correlating an already started model instance, in that case the PRT uses the correlationID found in the TN document to identify the mapped instanceID and corresponding model)
• if identified, whether this model is using a volatile tracking or not.

The internal method of the internal class (non documented PRT class - invoked by the wm.tn:handleBizdoc service) is PRTCrossRef.performInsert().

Any update on this issue. In between what I have noticed is that the performance is bit better if there are not many instances of the same model in the prt table. I mean if I delete all the rows for a given model ID and then recreate that model, the performance become a but better. I know this should never happen in production but is there any explanation for that or better a solution.

One more thing I have noticed is that the number of rows in the wmprocess table also is degrading the performance.

Please let me know if you need more information.

Ram Challuri

No update on kicking off a model without publishing a document.

For the performance items you mention, I’ve seen that is fairly important to keep your PRT tables trimmed down. You’ll want to schedule a DB trim action to remove “expired” entries in your tables. “Expired” is defined entirely by you but you’ll want to be as agressive as possible in deleting entries in all the PRT tables.

Keep 15 days worth of data, maybe 30, depending on how far you need to go back for troubleshooting or reprocessing. 90 days of data is probably too much (which is usually what business users claim they need–but that’s not usually based on anything other than gut feel).

Another thing I’ve run into is that there is always a desire to use the PRT tables as an archive of sorts. (The TN tables often get picked for this function too). This is not a good thing to do, IMO. The integration layer is not a good place to archive anything. If data must be archived, then do so outside of the PRT tables (or TN tables, or whatever). Keep the PRT tables for “in-transit” integrations only, with a minimal bit of old data to facilitate troubleshooting.

My .02

Just for kicks I tried to launch a model by directly invoking the service that is called by the trigger associated with the model (ie., launch a model without publishing document). It appeared to work in my case, although I am in no position to endorse this approach in general.

I invoked the following service with the following inputs.

wm.prt.dispatch:handlePublishedInput
triggerName(string)=model_three_step.Design_Server:trigger
documentType(string)=model_three_step_guts:doc_model_three_step
document(doc instance)=model_three_step_guts:doc_model_three_step

Again, I am no expert, just a curious bystander.