Problem enabling a process model via the WmMonitor

, ,
1

I created a new process model, generated the business process, and updated the process for monitoring with no problem. However, before running my process flow I tried enabling the process model in the monitor, and I got the following message:

A request to enable process model ‘DummyProcess’ has been submitted to Process Runtime.

Did I miss anything? Appreciate any insight.

2

It can take a while for the model to get enabled, just refresh the screen a few times. If it doesn’t get enabled, restart the IS, and try it again right after that. I think webMethods is working on a fix for this.

3

Thanks I tried all the above but didn’t work, ended up going directly to the process db and change the flag to equal ‘1’ for enabled.

4

That is not really good way to do it. The reason for the process not getting enabled could be because of various checks that the WmMonitor application is performing. A better option would be to recreate all the monitor related tables and regenerate the business process from the modeler. This is should do the trick. Of course the assumption is you do not have any other processes.

5

Model enable/disable is deferred and processed asynchronously via the publication of a document. This can take a while, but not forever.

If the enablement/disablement problem happens short after generating the model, it can have something to do with problem during the generation itself. The model generation operation may not report some kind of errors: check the server error log for entries on services such as �wm.prt.addFragment�. Such errors may be related to file systems permissions. Check if the folder �<package_of_model>/config/wmprt� and its contents are read-write. They must be writable for the model to generate correctly.

6

We’ve got instructions from webMethods on which are the right steps to take to enable a model during a deployment of a package:

  • First install the package.
  • Import the model in the modeler.
  • Run the service pub.prt.admin:scanPackge with the package name as input
  • Update the model for monitoring
  • Enable the model

We’ve had a lot of problems with enabling models, but when we follow these instructions, the models get enabled most of the time. Especially the scanPackage service is very important.

7

Shut down your Integration server and restart the Broker. That seemed to do the trick for me. As highlighted in an earlier thread there is an enbale event published to the broker and if the broker does not pick this up the model is not enabled. Restarting the broker forced it the process all queued document and this in turn enables the Model.

8

Advantage article:

“Unable to enable Process Model in WmMonitor”

http://advantage.webMethods.com/article/?id=1611541841

… explains that the thing which is supposed to respond to the ‘enable’ doc that WmMonitor publishes is the Trigger in the package that was generated from the Model - so your package for the model (and its Triggers) must be deployed and active for the WmMonitor ‘enable’ command to work.

I guess what I’m saying is that simply enabling the process in the database doesn’t necessarily ensure that the model will run. A well-configured PRT/Monitor environment should not require you to manually flip bits in the database.

Note that there is a dependancy between the version of WmMonitor package and the WmPRT package, so if the fixes in use are out-of-step or you’ve missed a dependancy from the readme then you could see inconsistencies that won’t be resolved by restarts/refreshes/regenerations.

However, restarting the Integration Server (another proposal in this thread) does the following things:

  1. WmPRT re-scans all installed packages for process fragments. You can cause this to happen without suffering a server restart by following the steps in article: http://advantage.webMethods.com/article/?id=1611760165 “Model transition conditions are changed, but when promoted to another environment they fail to take effect”
  2. Triggers are refreshed through Dispatcher, and problems with the document definitions in use in the environment will be logged.

So… a restart can also provide an opportunity to detect problems. There might be alerts issued during Integration Server startup that aren’t obvious at runtime, even with WmMonitor logging at level 8. Wind the logging level out to level 6 and look for Dispatcher, WmPRT, WmMonitor package and startup service errors at the time the server is started.

Regards,
Adrian

9

I faced the same issue of not able to enable or delete a business process that has been uploaded. What I did was to try to replicate the issue on another machine which is clean and it worked fine. On my own machine, it seems that the wM 7.1 installation conflicts with an existing wM 6.5 installation, although 7.1 was installed on a different directory and the ports were different. I also ensured that all 6.5 components were not started when running wM 7.1. Removing the 6.5 installation solved the issue. It seems that Developer 7.1 installation overwrites my Developer 6.5 installation. Lesson learnt…never install 2 different versions of wM on the same machine, even if they are installed on separate directories and ports.