About Events

An event signals a meaningful change from an SBM application or an external product. For example:

An issue defect management application in SBM raises an event every time a user submits a new defect.
A software build product raises an event every time a build completes.
Salesforce.com raises an event every time a potential customer is initially contacted.

Any SBM application or external product that is capable of calling a Web service can raise events in SBM. After an event is raised, the Event Manager receives it, and then calls the SBM Orchestration Engine to execute the asynchronous orchestration workflow linked to the event. The orchestration workflow could update an SBM item, create a new SBM item, and so on.

The orchestration workflow provides the integration point between an SBM application and an external product, or two SBM applications in the same process app or in different process apps. In the first case, the orchestration workflow can be initiated from either the application or the external product. In the second case, the orchestration workflow can be initiated from either application. Something happens in one that raises an event, and the orchestration workflow runs in response to the event and updates the other.

An event can be raised in the following ways:

From the SBM Application Engine by creating an asynchronous orchestration workflow action on a transition in an application workflow. You use the Action Wizard to create this type of event. You can raise the application's standard Event without Reply orchestration link ("the local event") to invoke orchestration workflows that were defined for use with the application, or use an imported orchestration link ("external event") to invoke any other orchestration workflow. For more information, see Tutorial: Calling an Orchestration Workflow from Any Application and Using the Action Wizard.
Note: When there are multiple asynchronous orchestration actions on the same transition, only one event of each event type is raised. Events start orchestration workflows that will run simultaneously depending on available resources, so the ordering of event actions on the Actions tab has no effect on the execution order of the orchestration workflows. See Considerations for Using Actions for details.
From an external product using any of the following:
- Event Manager Web service API
- E-mail message

The following diagram illustrates the way an event is processed.

Diagram of external event architecture

Remember: Events are relevant for asynchronous orchestration workflows only. For information about the differences between asynchronous and synchronous orchestration workflows, see Comparing Synchronous With Asynchronous Orchestration Workflows.

In addition to initiating an orchestration workflow, an event sends data to it.

For an event raised from an SBM application, the mappings are implicit, so you do not need to map application data into the event. You can select which fields from the primary application table to be sent with the event, and can define additional data to be sent with the event. To do this, click Event without Reply under the Orchestration Links heading in App Explorer. See About Orchestration Links for more information.
For an event that is not raised by the primary application, you must map application data into the event. In this case, you import an existing event definition or create a new custom event definition using SBM Composer. See About Application Links and Event Definitions and External Events for more information.

In certain external integrations with SBM, errors are handled in a limited way and cannot be automatically retried. You can manually retry these events in SBM Application Repository. For more information, see Retrying Failed Asynchronous Events.