Table of Contents

Search

  1. Preface
  2. Part 1: Using Process Developer
  3. Part 2: Creating and Modifying Processes
  4. Part 3: Functions, Events, Errors, and Correlation
  5. Part 4: Testing and Deployment
  6. Part 5: Process Central and Process Server (On-Premises)

Process Developer

Process Developer

Using System-Defined Events

Using System-Defined Events

Using System-Defined Events You can select a built-in system event to be used in event processing. This type of event is based on well-known Process Server events.
Defining a system event is different from defining an event in the PDD of a process. You do not use the Eventing tab of the PDD for system events. Instead, you create a process based on the Event Action system service, and in the Partner Links tab of the PDD, you specify a required service name for the My Role partnerlink. The details are provided below.
The following system events are available
  • AeEngineEvent
    See the Engine Event table below for a description of this event. In order to receive the
    AeEngine
    event, you must deploy a process, based on the Event-Action system service. The PDD of this process must contain the required service name
    AeEngineEvent
    (with
    portType EventActionPT
    ). For details, see Creating an Event-Action BPEL Process.
    When using this event, be careful using the
    getProcessState
    admin API call if another node could suspend the event. For example, if a node tries to load a process from a second node within the default 10 second process idle timeout, the engine will suspend threads in the node running the process so that the requesting node (node 1) can load them. Being suspended, however, triggers an engine event process that tries to get the process state. However, trying to get the process state from the node 1 also triggers a suspend, which again triggers the engine event process. An attempt is now made to get the process state from node 1. These actions repeatedly suspend the parent process over and over, which means the process will not return to a running state.
  • Task-Based Engine events
    See the Task-Based Engine Events table below for descriptions. In order to receive a task-based event, you must deploy a process, based on the Event-Action system service, containing one of the following required service names:
    • AeHumanTaskCreated
      . Use this service name only for the AeHumanTaskCreated event
    • AeHumanTaskEvent
      . Use this name only for the AeHumanTaskEvent event
Engine Event
Event Name
Description
Event Properties
AeEngineEvent
Fired when an engine event is fired. Engine events consist of the following. To filter an engine event, refer to its integer value:
  • PROCESS_CREATED (0)
  • PROCESS_COMPLETED (1)
  • PROCESS_SUSPENDED (2)
  • PROCESS_RESUMED (3)
  • PROCESS_STARTED (4)
  • PROCESS_RECREATED (5)
  • PROCESS_UNDER_COORD (6)
  • PROCESS_FAULTED (7)
  • ENGINE_STARTED (100)
  • ENGINE_STOPPED (101)
  • ENGINE_FAILED (102)
processId (long)
state (int). The integer values are shown to the left.
processName (QName) (Cannot be used in a "compare" statement)
processLocalName(string)
processTargetNamespace
timeStamp (Date)
invokerLocationPath (String) (ProcessUnderCoordination only)
parentProcessId (long) (ProcessUnderCoordination only)
Task-based Engine Events
Event Name
Description
Event Properties
AeHumanTaskCreated
Fired when a WS-HT task is created. By the time this event fires, the task is created and available for querying.
TaskPAProcessId (Double)
TaskPALocationId (Double)
TaskId (String)
TaskStatus (String)
AeHumanTaskEvent
Fired when a WS-HT task changes state for any reason, such as when claimed, started, added, commented, output is submitted, or completed.
TaskEventType (String)
TaskEventPrincipal (String)
TaskPAProcessId (Double)
TaskPALocationId (Double)
TaskId (String)
TaskStatus (String)

0 COMMENTS

We’d like to hear from you!