Execution Instance

The execution instance functionality presents long-running services current state.

The list presents the deployed services as group/artifact/version.

A long-running instance is defined as a service that is waiting for external input to continue. A decision service that would take 5 seconds to execute would never show up on this screen because it is never waiting for an external input to continue.

From the list, clicking on a service brings up the service specific instances view.

Specific service instances

When viewing the running instances of a specific service deployment, the following information is provided:

Created

The creation timestamp of this instance.

Name

The user defined name of the instance. If tags were defined, they are also displayed in that column.

Updated

The updated timestamp of this instance. This timestamp represents the last moment the instance reached a wait state.

Actions

Clicking on a row will bring a user interface presenting the details of the resume points that can be used to trigger the service instance.

There are several actions in the last column:

  1. View and administrate service instance by clicking on icon

  2. Copy instance identifier by clicking on icon

  3. Delete an instance by clicking on icon

View and administrate service instance

Cloud execution allows to open service instance as model to be able to inspect its data and state such as

  • completed activities

  • currently active activities

  • activities in error

On top of that, administrators can also perform operations from within the model:

  • manage currently active tokens (delete the token, move from one activity to another or create new tokens)

  • open form for given token

  • reassign performers of user and manual tasks

  • alter data objects

  • retrigger failed activities in case service instance is in error state

Detailed history view provides trace of execution with information about completion date and time of the activity and in case of user/manual tasks, who completed that task.

A live view of the service instance works best with Audit execution profile enabled. This will provide most up to date information about executed activities. Audit execution profile can be set during deployment of the service.

Auto refresh

Service instances are automatically refreshed based on changes in the runtime environment this cloud execution is connected to. With that, instances are reloaded on the page as soon as new instances are added or deleted.

Auto refresh respects current filter and pagination settings to avoid unneeded changes of the content.

Auto refresh can also be disabled by turning off Auto refresh switch at the top of the page. Auto refresh setting is remembered.

PermaLink to specific service instances

To simplify access from outside, specific service instances can also be accessed with permalink.

Example: https://host/cloudexecution/#/prod/instances/bpmn/finance/payroll-service/1.0

where:

  • host - is the host (and optionally port) of Digital Enterprise Suite or Digital Distributed Container

  • prod - is the environment service is deployed to

  • bpmn - is the type of the service, allowed values are (bpmn, cmmn)

  • finance - is the group of the service

  • payroll-service - is the artifact of the service

  • 1.0 - is the version of the service (latest can also be used)

Migrate service instances

Service instances that are long-running can be active for days, weeks, months or even years. During the lifetime of the service instance, there might be a newer version of the service deployed. At the time when new version is deployed, administrator of that service can decide what to do with currently active instances:

  • leave them on the version of the service they started with

  • migrate them to newer version

Ideally, when possible, instances should be left to complete on the version they were started. Migrating service instances to a different version carries risks and needs to be done only if required (e.g., legal requirements, critical problem in previous version). When filtering the instance view, it is possible to migrate only some of the service instances.

The migration of service instance from one version to another will not affect the instance data objects or case file items. A manual data update may be required in migrations where the data aspect of the service changed.

A wizard guides the migration and validate the compatibility between the two versions for the migration. It also offers an opportunity to provide a mapping for definition mismatches.

Consult the dedicated Instance migration page to learn about the technical details involved.