There are no enabled Processes matching this trigger

, ,
1

Hi,
After wM migration 8.2->9.6 don’t start process instances.
Log fragment after document publication:

[ISS.0098.0049C] Exception:com.wm.app.b2b.server.ServiceException: [PRT.0101.9613] There are no enabled Processes matching this trigger: xxx:subscriptionTrigger while executing trigger. Rejecting Document for TriggerStore:xxx

Installed fixes:
PRT_9.6_Fix6
MON_9.6_Fix0006
IS_9.6_Core_Fix6
MON_9.6_MWS_Fix8

Do you have any idea?

Thanks for help.

2

May be couple of issues.

  1. check MwS, weather model enabled or not, enable it, if it is not working then use monitor service “pub.monitor.process.modelControl:changeModelEnabled”
  2. If still problem persists, recompile the model using latest designer, which reestablishes broker metadata so that document will be associated and recognized
  3. If still problem persists, send the complete PRT log

HTH
!Raj

3

If your process is enabled and it has been deployed to the target, it may be that your Process Engine has not yet become aware of it. I’ve seen this issue during deployment a couple of times. There’s a service in the WmPRT package that is pretty handy called scanPackage. Simply run this service and provide the name of the package containing your process fragments. This will ensure the Process Engine becomes aware of it and we can at least eliminate that as a variable.

If this and Raj’s suggestions don’t solve it, let us know.

Percio

2 Likes
4

Hi Jaroslaw,

what is your messaging provider?
Broker or UM?

Did you restart the IS after migrating the sources and configuring the Messaging Provider?
This will create the neccessary client objects on the messaging provider.

Regards,
Holger

5

Hello,

As a continuation of Holger’s response, if your messaging provider is Broker, you can:

  • login in the MWS Administration console
  • go to Administration->Broker->Clients
  • search there after your trigger
  • open it and in the tab “Subscriptions” check what are the subscriptions for the trigger.

If the process does not appear there I think Percio has exposed the solution.

Best regards,
Vlad Turian

6

Thanks for all this information.
I checked all this.

  • subscription trigger is active but the transition trigger of the most current version of the process is not starting
  • I did run the scanPackage function. No error message
  • I run the Broker on WM version 9.8
  • I have 2 versions of a process deployed ( version 3 and version 4) Only version 4 is activated.
  • the subscription trigger received all the messages ( document ) I published.

But I always get the error message “There are no enabled Processes matching this trigger: Handle_PCRB_Lots.EarlyLotRelease.Hosting:subscriptionTrigger”

How is the connection between subscription trigger ( waiting for the document ) and the most current transition trigger ( in my case version 4) ?

Any help is welcome. I’m searching for some days already.
Jürgen

7

Hi Jürgen,

subscription trigger takes care of the document Types needed to start or continue a process instance.
transition trigger takes care of the transitions between the steps.

Please check your messaging provider for the clients.
If possible/feasible, delete the clients and reload the process package.
This should recreate the clients.

Regards,
Holger

8

Navigate to the home page of the Process Engine (e.g. http://localhost:5555/WmPRT). Click around the menu options. Do you see anything out of the ordinary? Do you see your process listed under the Process menu option?

Percio

9

Hi,

It seems you may have completed the following migration steps with a BPM project:

  • install a new SAG 9.6 platform (IS+PE+MWS+DB) side-by-side the old 8.2.2 platform
  • migrated the old 8.2.2 platform’s data to the new platform
  • install the new SAG 9.6 Designer tool
  • import the 8.2.2 BPM project to the new 9.6 Designer and updated to the new format as requested
  • changed the project’s version number, saved, built and deployed on the new platform
  • enabled for execution the new process version and disabled the old version

This should ensure all new instances of the process will be created with the new version.
Depending on certain conditions, existing running process instances of the old version can be still allowed to run to completion using that version’s configuration; those same instances can be upgraded to the new version if specific conditions are met (no missing steps on the new version and others).

However, it seems the migration steps still disregard certain legacy settings which my hinder your successful migration procedures, namely the stricter naming conventions for process names.

To have a better grip on the problem you must go through the following steps:

  • capture the broker documents in the broker server using MWS (lock the broker client queue and list its contents - you should save the queue to file)
  • list all the conditions the broker trigger Handle_PCRB_Lots.EarlyLotRelease.Hosting:subscriptionTrigger has (on the Designer - the MWS/broker view will only show you the conditions the broker can handle directly - the IS may be dealing with a larger set)
  • compare values of the broker document with those conditions
  • you may even debug the trigger, injecting the values you retrieved from the broker queue

You may have more detailed troubleshooting techniques here: [url]https://empower.softwareag.com/sl24sec/SecuredServices/document/java/Troubleshooting/atg/Process_Engine_Troubleshooting.html[/url]

POSSIBLE ROOT CAUSE:
I suspect you will find the process new version’s PROCESSKEY will be different from the previous version’s.

That is easily checked in the following places:

  • in the created process package in the Integration Server (packages//config/wmprt/*.xml)
  • in the PRT database’s table WMPROCESSDEFINITION, the PROCESSKEY field

This is because your process name has underscores in it. It is not an error, and they are allowed (but a small note somewhere warns you should only use alphanumeric characters) but SAG chose to change the way they are encoded from 7.1.2 onwards and versions up to 8.2.1 may have been keeping the compatibility flag without warning.

Before 8.2.2 (and possible even before) the PROCESSKEY of a process would be computed from their name by ‘punyencoding’ following a strategy close to RFC3492, but now they are just simple copied over.

A simple sign is the PROCESSKEY having the form ‘pq__<something similar to the process’ name>__pq’ and not ‘<process’ name>'. See if creating processes with and without underscores ‘_’ makes any difference.

But none of the migration manuals I have read so far explicit warn of this situation.

POSSIBLE SOLUTION
Now, for the solution I have found (when migrating from 7.1.2 to 8.2.2 but should be applicable here), I’m basing my actions on these references
[url]https://empower.softwareag.com/sl24sec/fixsis_extern/FIXSIS2/ALL/WSI/821/SCG_8.2_SP1_BPM_Fix1_Readme.txt[/url]
[url]https://empower.softwareag.com/sl24sec/SecuredServices/KCFullTextASP/viewing/view.asp?prdfamily=Suite&KEY=104876-4181971&DSN=PIVOTAL&DST=TCD[/url]

  • make certain you have the absolute most updated fixes on the SAG platform, including Integration Server, Processing Engine, Database configuration, Deployer AND Designer
  • Delete the latest version from the database (could be impossible if you have already run new instances) - this means changing table MWPROCESSDEFINITION and others by hand – PROCEED WITH EXTREME CAUTION!
  • If that is not possible, start with the db state before migration and migrate it again to the new platform’s db
  • add the compatibility flag in the 9.6 Designer and start it.
  • for testing the flag is running: create a new empty process with a similar name to the actual process you are dealing, create, build and upload, and check its PROCESSKEY as before
  • if the test is satisfactory, proceed with opening the old process, as you already did, converting to the new version, saving, building and uploading

Good luck.

10

SHORT TROUBLESHOOTING VERSION:

  • check the PROCESSKEY of the process’s versions on the WMPROCESSDEFINITION table to see if they all equal (Percio’s tip will also yield this information)
  • if not, proceed with the my long version explanation and resolution
  • if they are, compare closely the broker documents with the broker client and the broker trigger filters.

Best Regards,

11

Thanks to all your comments.
I found the first time a process overview in IS “…/WmPRT”. Thanks to Percio!

The root cause for my problem is a wrong deployment. ( and less knowledge )
The Hosting.xml file is missing at IS.
Does anyone knows a good Wiki or documentation for deployment? I know the SAG documentation. This docu describes how to use the deployer, but not how to deploy a BPM project.

  • What is the best definition of deployment projects?
  • What is the right sequence?

Thanks
Jürgen

1 Like
12

Hi Jürgen,

a best practice is to first deploy the logic implementation in a separate package as a regular IS&TN deployment set.
In a second deployment set of type BPMS (Designer) deploy the Process models together with their generated packages while setting the references to the logic implementation as “Exists”.

By doing so it is not neccessary to deploy the whole process model again when there are only changes to the logic implementation.

When deploying Tasks for Process Models, the tasks need to be deployed to MWS before deploying the Process models.

Regards,
Holger

13

Thanks Holger.

I will take your recommendations. Actually I have 4 different projects and deploy IS, CAF ( Tasks & UI), Process, Roles.
When I deploy the Process I get the error, that the “config/wmprt/Handle_PCRB_Lots.EarlyLotRelease.Handle_PCRB_Lots_EarlyLotRelease4.Hosting.xml”
is missing.

When I say " it exists " → I get an error during map step, saying " xxx does not exist on traget "
When I select " ignore " → Then the process is not listed under “…/WmPRT” on the IS

How do I deploy this Process Hosting XML?
It is not part of the generated process package in IS.
And I cannot find it under MWS files during IS deployment.

I stuck here since many days. Any help appreciated.

Thanks
Jürgen

14

So my process is listed under /WmPRT.
I did a refresh of WmPRT again. I do not know where the Hosting.XML file is located but if it works then it is fine with me.

Thanks
Jürgen

15

Hi Jürgen,

according to the mentioned path the file should be under generated Process Package.

One service which might be helpful in the future:
pub.prt.admin:scanPackage

This will scan and reload the Process information from the package specified.

Regards,
Holger

16

Hi,

If using the Deployer, it helps to have the packages projects separated from the models project.

I find it easier to deploy all package assets (and users/groups/acls) and only after that, deploy the model.

Best Regards,

1 Like
17

Hi,

Please verify you have the latest WmDesigner and WmDeployer fixes and any related fixes to the IS and DB.

You could also try to cleanup the WmDeployer/replicate folders from older projects before importing the process project again in WmDeployer.

Best Regards,

1 Like
18

Can you please also check, triggers were updated for the newer version of the model ?

Thanks,

19

Thanks!!!

20

Having this same problem. Tried to navigate around http://locahost:5555/WmPRT but it’s empty ;(