Management → Managing Applications → Application Processes → Application Process Step Details → Application Process Utility Steps
Several utility steps are provided for application processes.
Locks are typically used to prevent specific processes from modifying the same resource at the same time, such as when a database is being updated.
In an Acquire Lock step, the process tries to acquire a lock with the specified name. If there is no other lock with that exact name, the process acquires the lock with that name and continues. If another process is using a lock with that exact name, the process waits until the lock is released by the other process. Any processes that access the resource without a lock or with a lock of a different name do not wait on this lock.
Locks are released automatically when the process completes, but you can also release the lock using the Release Lock step if you need to release it explicitly before continuing later steps in a process. Administrators can also release locks. See Managing Locks.
The following table describes the property for these steps.
| Property | Description |
|---|---|
| Lock Name | Specify the lock name. The default setting is as follows:
${p:application.name}-${p:applicationProcess.name}-${p:environment.name}
Tip: The default lock name setting is set using a default variable. Therefore, to make the lock names
exactly the same for different objects and processes, you can enter a static
string for the name or use variables that will resolve to the same in both
processes. For example, if you want to lock a resource against concurrent use
for two processes in different components that are mapped to the same resource,
you could use
${p:resource.name} as the lock name for
both.
|
| Property | Description |
|---|---|
| Status | Values: Success or Failed |
| Property | Description |
|---|---|
| Sleep Time | Default: 30 |
The Join step enables you to join steps in a process. There are no properties for this step.
For the Join step to continue processing on to its outboard connections, all its inbound connection paths must be valid. To be valid, all that should evaluate to success do so, all that should evaluate to failure do so, all that should evaluate to any value do so, and all that should evaluate to a specific switch value do so.
You can do an implicit join without the Join step by having multiple inbound connections for another step. Regardless of whether it is an implicit or explicit join, all incoming connections must be valid for the joining step to be executed.
One reason you should choose an explicit Join step is when your process has multiple steps that must all complete to a certain outcome and then should continue on to multiple outbound steps without additional processing between them.
The Manual Application Task step enables you to interrupt a process until some manual intervention is performed according to a pre-configured application task. Application tasks must be set for an application before you can select them for this step. See Application Tasks.
The following table describes the properties for this step.
| Field | Description |
|---|---|
| Name | Enter a descriptive name for the step. |
| Task Definition | Used to select a previously-defined user-defined task. See Application Tasks. |
| Environment Role | Select the role expected to respond. The user mapped to this role must respond to the generated work item before the process can continue. |
| Application Role | Select the role expected to respond. The user mapped to this role must respond to the generated work item before the process can continue. |
If both roles are selected, all affected users must respond before the process can continue.
Copyright © 2011–2018 Serena Software, Inc., a Micro Focus company. All rights reserved.