The following terms are defined in Petals ESB context and must be used in all technical and functional documents.
|| Terms \\ || Definition || Variable names in source code \\ ||
| * Process | Set of steps assembled to define a processing. \\ | |
| * Process identifier | Identifier associated to a process. \\ | * processId |
| * Process instance | When a process is invoked, a process instance is created representing the process execution. \\ | |
| * Process instance identifier | It is a GUUID (Global Universal Unique Identifier) identifying *one and only one process instance*. \\
It can be initialized from outside client when entering in Petals ESB (the outside client is responsible of the identifier uniqueness) and transmitted to application resources to retrieve all steps of a global business process. Inside Petals ESB, this identifier is automatically transmitted step by step. \\ | * processInstanceId
* -correlationId-
* -processExecutionId-
* -processRequestId-
* -globalMessageId-
* -contextUuid- |
| * Process loop identifier | This identifier is used to identify the loop iteration in which steps are executed. Without the process instance identifier, this identifier has no real sens. It can be initialized from outside client when entering in Petals ESB and transmitted to application resources. \\
This identifier is formed as: <main-loop-id>\[glossary:-<sub-loop-id>\] where: \\
* <main-loop-id> is the process loop identifier of the first process step. It is defined as '0' if no value was provided by a outside client,
* <sub-loop-id> is defined as: <iteration-number>\[glossary:-<sub-loop-id>\] where <iteration-number> is the loop iteration number starting to 0. <sub-loop-id> will identify sub-loop iterations of the current loop. | * processLoopId |
| * Process branch identifier | This identifier is used to identify the parallel branch in which steps are executed. Without the process instance identifier, this identifier has no real sens. It can be initialized from outside client when entering in Petals ESB and transmitted to application resources. \\
This identifier is formed as: <main-branch-id>\[glossary:-<sub-branch-id>\] where: \\
* <main-branch-id> is the process branch identifier of the process main branch. It is defined as '0' if no value was provided by a outside client,
* <sub-branch-id> is defined as: <branch-id>\[glossary:-<sub-branch-id>\] where <branch-id> is a number starting to 0 and incremented by each created branch. <sub-branch-id> will identify a sub-branch of the current branch. | * processBranchId
* -branchId- |
| * Component name | A *component name* is an unique name assigned to the component instance at installation time. \\ | * componentName
* -loggerName- |
| * Trace code | A code identifying uniquely a trace type in log. For example, all service invocations are logged on the consumer side with the same code. \\ | * traceCode |
| * Log level | All log traces have a level indicating their severity. The logging system can be configured to filter traces to log against their severity (see [petalsesbsnapshot:Logging in Petals]). Available severity are: \\
* *ERROR*: An error occurs when the service can not be provided:
** In a Petals ESB container point of view, an error is something that stops the processing of an internal component. Consequently, the Petals ESB is stopped because it can assume its functions.
** In a component (BC/SE) point of view, an error is something that stops the processing of the SE or BC, but other components are always running correctly. Consequently, the component could be stopped.
** In a service (service-unit) point of view, an error is something that stops the processing of a service, each service invocation will fail, but other services deployed on the same component are correctly running. Consequently, the service could be stopped.
* *WARNING*: A warning occurs when the service is partially provided and is compensated by a default behavior or it could be hot-fixed without restart or re-installation.
* *INFO*: The information level highlights the provided service. Such a trace is logged parsimoniously. For example, service life cycle states are logged with this level.
* *CONFIG*: All parameter values are logged with this level.
* *MONIT*: This level is used to trace incoming and outgoing service messages to be able to monitor process executions in a business point of view.
* *DEBUG*: All traces that can help a problem analysis are logged with this level. | |
{petalslink:type=TODO Add terms}* Petals topology,
* Petals node (= \[glossary:JBI\] container),
* Petals network (= Petals topology instance),
* Petals domain,
* Petals sub-domain
* Distribution peer-to-peer
* Static topology,
* Dynamic topology
* Self discovery{petalslink}
\\
{info:title=Global terms utilization}
This previous terms are not only used for BPEL
{info}
|| Terms \\ || Definition || Variable names in source code \\ ||
| * Process | Set of steps assembled to define a processing. \\ | |
| * Process identifier | Identifier associated to a process. \\ | * processId |
| * Process instance | When a process is invoked, a process instance is created representing the process execution. \\ | |
| * Process instance identifier | It is a GUUID (Global Universal Unique Identifier) identifying *one and only one process instance*. \\
It can be initialized from outside client when entering in Petals ESB (the outside client is responsible of the identifier uniqueness) and transmitted to application resources to retrieve all steps of a global business process. Inside Petals ESB, this identifier is automatically transmitted step by step. \\ | * processInstanceId
* -correlationId-
* -processExecutionId-
* -processRequestId-
* -globalMessageId-
* -contextUuid- |
| * Process loop identifier | This identifier is used to identify the loop iteration in which steps are executed. Without the process instance identifier, this identifier has no real sens. It can be initialized from outside client when entering in Petals ESB and transmitted to application resources. \\
This identifier is formed as: <main-loop-id>\[glossary:-<sub-loop-id>\] where: \\
* <main-loop-id> is the process loop identifier of the first process step. It is defined as '0' if no value was provided by a outside client,
* <sub-loop-id> is defined as: <iteration-number>\[glossary:-<sub-loop-id>\] where <iteration-number> is the loop iteration number starting to 0. <sub-loop-id> will identify sub-loop iterations of the current loop. | * processLoopId |
| * Process branch identifier | This identifier is used to identify the parallel branch in which steps are executed. Without the process instance identifier, this identifier has no real sens. It can be initialized from outside client when entering in Petals ESB and transmitted to application resources. \\
This identifier is formed as: <main-branch-id>\[glossary:-<sub-branch-id>\] where: \\
* <main-branch-id> is the process branch identifier of the process main branch. It is defined as '0' if no value was provided by a outside client,
* <sub-branch-id> is defined as: <branch-id>\[glossary:-<sub-branch-id>\] where <branch-id> is a number starting to 0 and incremented by each created branch. <sub-branch-id> will identify a sub-branch of the current branch. | * processBranchId
* -branchId- |
| * Component name | A *component name* is an unique name assigned to the component instance at installation time. \\ | * componentName
* -loggerName- |
| * Trace code | A code identifying uniquely a trace type in log. For example, all service invocations are logged on the consumer side with the same code. \\ | * traceCode |
| * Log level | All log traces have a level indicating their severity. The logging system can be configured to filter traces to log against their severity (see [petalsesbsnapshot:Logging in Petals]). Available severity are: \\
* *ERROR*: An error occurs when the service can not be provided:
** In a Petals ESB container point of view, an error is something that stops the processing of an internal component. Consequently, the Petals ESB is stopped because it can assume its functions.
** In a component (BC/SE) point of view, an error is something that stops the processing of the SE or BC, but other components are always running correctly. Consequently, the component could be stopped.
** In a service (service-unit) point of view, an error is something that stops the processing of a service, each service invocation will fail, but other services deployed on the same component are correctly running. Consequently, the service could be stopped.
* *WARNING*: A warning occurs when the service is partially provided and is compensated by a default behavior or it could be hot-fixed without restart or re-installation.
* *INFO*: The information level highlights the provided service. Such a trace is logged parsimoniously. For example, service life cycle states are logged with this level.
* *CONFIG*: All parameter values are logged with this level.
* *MONIT*: This level is used to trace incoming and outgoing service messages to be able to monitor process executions in a business point of view.
* *DEBUG*: All traces that can help a problem analysis are logged with this level. | |
{petalslink:type=TODO Add terms}* Petals topology,
* Petals node (= \[glossary:JBI\] container),
* Petals network (= Petals topology instance),
* Petals domain,
* Petals sub-domain
* Distribution peer-to-peer
* Static topology,
* Dynamic topology
* Self discovery{petalslink}
\\
{info:title=Global terms utilization}
This previous terms are not only used for BPEL
{info}