Model Components

Every model includes:

Model Metadata

A model is defined by unique metadata.

  • Model name

  • Model description

  • Singular and plural terms for model-specific instances that are understandable by business users, such as “order” and “orders”

  • Icon representing the model

  • Milestones

  • Indicators

  • Unique Instance Identifier


Milestones are a key abstraction in an Integration Insight model. They are points in a business process that represent progress and map to at least one point in the business process implementation.

Generally, a Business User creates the milestones iteratively with appropriate metadata.

For business processes implemented in theIntegrations feature in Oracle Integration, an Integration Architect then refines the milestones and maps them to appropriate points in the business process implementation.

Milestones in Model Editor

Characteristics of a milestone include:

  • Atomicity: A milestone has no entry or exit point. A milestone is considered to be passed, but you are never in a milestone. A milestone has no duration and is passed atomically. However, it is important to consider the duration it takes to reach from one milestone to another.

  • No enforced ordering: Milestones can be passed in any order and repeatedly. However, the system does maintain the natural ordering in which the milestones were defined in the model.

    For example, Order Received generally happens before Order Complete. The system lists milestones in this natural order in the context of selection and reporting.

  • Semantic types: Milestones may have one or more semantic classifications that describe the milestone’s role in the execution of a business process. See the list of milestone types below.

  • Implementation mapping: Milestones are mapped to points in a business process implementation that indicate that the milestone has been passed.

  • Indicators: Milestones can have indicators associated with them that are extracted when the milestone is passed. These indicators represent the state of the instance when the milestone is passed, and have a variety of different semantic options.

Milestones are of the following types:

  • Initial: A model instance is assumed to be valid when a milestone of type Initial is passed. This concept is key to filtering out instances that may already be in flight when Integration Insight starts monitoring a runtime engine. An instance that has most recently passed an Initial milestone is in an Active state.

  • Terminal: Represents an expected end to the model instance. For example, a milestone "Order Complete" that represents the completion of an order might be modeled as a Terminal milestone. Integration Insight does not enforce the end of an instance after a Terminal milestone, and further milestones may be passed. An instance is in a Completed state when the last milestone passed was a Terminal milestone.

  • Error: Represents a milestone that reflects some business error condition encountered in the execution of the business process. The business process implementation may account for and recover from errors, and thus Error milestones are not necessarily also Terminal. An instance that has most recently passed an Error milestone is in an Error state.

  • Terminal Error: Represents an Error milestone, which also represents the expected end of the business process processing. An instance that reaches a Terminal Error milestone is in a Failed state.

  • Standard: Represents a milestone that is neither Terminal nor Error. An instance that has most recently passed a Standard milestone is in an Active state.

Every model instance must pass through at least an Initial and a Terminal milestone.

See Create a Milestone.


Indicators represent metrics that are unique to a business process, and are extracted when milestones are passed in a business process implementation.

Indicators allow business users to gain insight into the proper functioning of a business process, and also allow comparisons between instances (like each order or service request). They help to quantify the performance of the business, and are used to create dashboards and reports for tracking business metrics.

There are two types of indicators:

  • Measures identify values that allow the state of a business process to be quantified. A single measure can change over the lifecycle of a model instance. For example, a typical order a business process might define measures for Total Order Value or Item Count. Or, the discount amount may change during an opportunity to order business process because the Quote Modified milestone can be passed more than once.

  • Dimensions provide a type of grouping and categorization of instances, allowing for slicing and dicing of aggregate integration measures. For example, a typical order a business process might define dimensions for Geographic Region, Sales Channel, or Product Category.

See Create Indicators.

Unique Instance Identifier

Every Integration Insight model must have an identifier defined. This identifier specifies the value that should be extracted at runtime as the unique instance identifier for every instance of the business process defined by the model.

For example, an identifier of orderID specifies that each unique orderID value is considered to be a separate instance of your business process, and that value is the unique instance identifier. All events that occur within a business process for the same instance use the unique instance identifier to associate the events with that instance.

Furthermore, once an identifier value has been extracted for an instance, a different value cannot be extracted (that is, you cannot change the value of the unique instance identifier for an instance). You can correlate additional identifiers for a model for more complex business flows, like correlating an order ID to a payment ID to an inventory ID.

If your business process spans multiple integrations, see Event Correlation Across Multiple Integrations.

See Create a Unique Instance Identifier.

Event Correlation Across Multiple Integrations

Integration Insight uses the unique instance identifier to grant you visibility into your entire business process, even if it is implemented in more than one integration.

In a single integration, all business process events are correlated by the unique instance identifier, such as an order number, extracted from the integration. Events with the same order number are considered part of the same order, or instance. If you want to monitor an end-to-end business process that spans more than one integration, you need a way to correlate the events belonging to all the integrations.

You can associate a unique instance identifier to a separate milestone for each integration in your business process. When additional integrations are invoked, the unique instance identifier can be extracted again when the specified milestone is passed. All events, regardless of the integration that sends them, that have the same unique instance identifier value are considered part of the same instance. For example, if your business process is implemented across two integrations, and the order number is extracted from the first integration, when the second integration is invoked you can extract the order number a second time to correlate its events as part of the same order.

You can perform as many additional associations as your business process requires. Each additional association must be made to a different milestone in your model.

See Add Additional Unique Instance Identifier Associations.