Error while calling a subprocess

When a new model is imported into an environment it gets propagated from the Process Design Engine to the Execution Engines so that these last engines can instantiate it as a sub-process as part of a running instance.

Under some edge cases when an import is done during high load the model might not fully propagate to the EXEC engines. In that case you can still launch the process model as a standalone (since this happens in the Design engine) but not as a sub-process (which happens in the EXEC engines) generating this error:

"Process model not found on Execution server for sub process invocation. A Request to Design server has been made."

This error has nothing to do with security at all.

To address the issue we need to force the propagation of the model to the EXECs. The way you do it is you start a new instance of the model used in the sub-process activity throwing the error but you start it as a standalone process not as a sub-process.

Start several dummy instances like this until there's at least one instance on each EXEC engine. You can check this by using a report with a column defined as

=process_ee_id()

which shows on what EXEC engine the process is running.

Keep in mind that the workaround is to launch the sub-process MODEL not the PARENT as a standalone process, meaning it will run on its own without a parent.

When a new model is imported into an environment it gets propagated from the Process Design Engine to the Execution Engines so that these last engines can instantiate it as a sub-process as part of a running instance.

Under some edge cases when an import is done during high load the model might not fully propagate to the EXEC engines. In that case you can still launch the process model as a standalone (since this happens in the Design engine) but not as a sub-process (which happens in the EXEC engines) generating this error:

"Process model not found on Execution server for sub process invocation. A Request to Design server has been made."

This error has nothing to do with security at all.

To address the issue we need to force the propagation of the model to the EXECs. The way you do it is you start a new instance of the model used in the sub-process activity throwing the error but you start it as a standalone process not as a sub-process.

Start several dummy instances like this until there's at least one instance on each EXEC engine. You can check this by using a report with a column defined as

=process_ee_id()

which shows on what EXEC engine the process is running.

Keep in mind that the workaround is to launch the sub-process MODEL not the PARENT as a standalone process, meaning it will run on its own without a parent.