Service Level Agreements (SLAs)

A Service Level Agreement (SLA) can be thought of a target of service performance or quality that is desired to be met during the execution of a process. An example of an SLA might be "When an order is received, it is shipped within 3 days". As processes execute, we hope that they meet these SLAs. IBPM can be configured to monitor the operation of processes and if an SLA condition is not being met, trigger some attention that will inform us that we have an issue that needs addressed. When an SLA is not met, we say that the SLA has been violated.

IBPM does not trigger an SLA exception when that logical exception occurs. Instead, IBPM evaluates SLAs only when an activity starts or completes. What this means is that if an SLA is violated for a process, we aren't informed until perhaps long after an SLA has failed. The IBPM environment informs only that past SLAs were not met. If real time notification that a time based SLA has been violated is required then Timer Events can be associated with activities to trigger actions if the activities have not been completed within a certain period.

Creating SLAs

SLA definitions are created from within the Decisions category of the Library.

The wizard for the creation of a new SLA prompts us for a name of the SLA.

The SLA has its own editor into which the details of that SLA can be entered.

The trigger option can be one of the following:


The condition is a complex combination expression

It starts with a predicate which can be:


The Consequence section defines what happens if the SLA is violated. It can be one or both of:

If we define a process to be started, the process must be defined as having following inputs:

|| |Input variable name|Data Type| |violationRecord|SLAViolationRecord| |parameters|XMLElement|

This is shown in the following image of the Variables for a BPD.

Page 2

No Comments
Back to top