2 Models
A model provides a grammar for describing the aspects of an application that are key for tracking business performance and mapping those concepts to existing software application implementation. In general, models of a high-level application are defined through an iterative collaboration between a business user and an architect. The business user generally describes the high-level concepts associated with an integration application, whereas the architect refines those concepts and maps them to an application implementation. Once the model is defined and mapped, the system starts collecting metrics associated with instances of the business model. The metrics are used to render dashboards and reports.
Any model includes:
-
Basic metadata. For more information, see Model Metadata.
-
Milestones and associated indicators. For more information, see Indicators.
-
Unique Instance Identifier. For more information, see Unique Instance Identifier.
2.1 Model Metadata
A model metadata constitutes the following:
-
Model name
-
Model description
-
Natural language business model specific singular and plural terms for instances; for example, “order” and “orders”
-
Icon representing the model
The model metadata is unique for each model in the application.
2.2 Model Summary Cards
Business owners often want to see a quick overview of the performance of their business. Consoles support this, but require users to open each console individually and inspect the status of the milestone dashboards.
Model summary cards provide an easy way for business owners to see important business metrics at a glance, for multiple models, and all on the Insight home page.
You can add a maximum of six models to the Home page. See Model Summary Cards in Using Oracle Real-Time Integration Business Insight for more information.
2.3 Milestones
Milestones represent a key abstraction in an integration application model. They are points in an integration application that represent business progress and map to at least one point in the application implementation. Generally, a business user defines the milestones iteratively and creates the milestones with appropriate metadata. The architect then refines the milestones by mapping them to appropriate points in the application implementation.
2.3.1 Characteristics of Milestones
Characteristics of a milestone include:
-
Atomicity: A milestone has no entry/exit point. A milestone is considered to be passed, but you are never in a milestone. A milestone has zero 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. There is no predefined order for the milestones. 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 an application’s execution. See also, Types of Milestones.
-
Implementation Mapping: Milestones are mapped to points in an application 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.
For more information, see Indicators.
2.3.2 Types of Milestones
Milestones are of the following types:
-
Initial: An instance is assumed to be valid by Insight when a milestone of type "Initial" is passed. This concept is key to filtering out instances that may already be in flight when Insight starts monitoring a runtime engine. An instance which has most recently passed an initial milestone is considered “active.”
-
Terminal: Represents an expected end to the instance associated with the business model. For example, a milestone representing the completion of an order, "Order Complete" might be modeled as a terminal milestone. Insight does not enforce instance cessation after a terminal milestone, and further milestones may be passed. An Insight instance is considered "complete" when the last milestone passed was a terminal milestone.
-
Error: Represents a milestone that reflects some business error condition being encountered in the execution of the application. The application implementation may account for and recover from errors, and thus error milestones are not necessarily also terminal. An instance which has most recently passed an error milestone is considered “error.”
-
Terminal Error: Represents an error milestone, which also represents the expected end of the application processing. An instance which reaches a Terminal Error milestone is considered to be “failed.”
-
Standard: A milestone that is neither terminal nor error is called a standard milestone. An instance, which has most recently passed a standard milestone is considered “active.”
Every model must pass through at least an Initial and a Terminal milestone.
2.4 Unique Instance Identifier
Every Insight model must have exactly one identifier defined. The identifier guarantees uniqueness among all integration instances. Furthermore, once an identifier value has been extracted for an instance, a different value cannot be extracted (i.e., you cannot change the value of the identifier for an instance).
2.5 Indicators
Indicators are key pieces of raw business data that are extracted as Insight observes the execution of application instances. Indicators allow business users to gain insight into the proper functioning of the application, and also allow comparisons between application instances.
Indicators have the following metadata:
-
Name
-
Natural language description
-
Use as filter criteria — determines whether this indicator can be used as part of the filter criteria in the console (for example, filtering dashboards.)
-
Associated Milestone — milestone in which the indicator is extracted
-
Implementation Mapping(s) — Indicators use their associated milestone’s mapping. This allows Insight to extract the indicator values at the appropriate point in the implementation. Indicators can be Dimensions or Measures. They are collected each time the associated milestone is passed updating the extracted values while Identifiers are collected only once and do not change.
For more information, see Dimensions, Measures, and Unique Instance Identifier.
-
Extraction Criteria — uses XPath functions to define how values are extracted from message payloads of simple types and XML types. Non-XML types like Javascript variables and others are not supported.
2.6 Model Lifecycle and Activation
A newly created model is in Draft state until the model is activated. Only activated models collect metrics. While a model is being activated, it is temporarily in the state of Activation in Progress. If activation is unsuccessful, the state is updated to Activation Failed. If the activation is successful, the state changes to Activated. A model can be deactivated as a result of a change to the underlying implementation, or a user can deactivate it – in either case the model is in Deactivated state with additional information available on hover.
To make changes to an active model, a new Draft is created, which can be activated after the changes have been completed.
2.6.1 Model Lifecycle States
Any model passes through the following lifecycle states:
-
Draft: In this state, changes can be made to the model and no metrics are collected. A draft model supports an Export action using which you can export a model and import it into the application.
-
In Progress: A model is this state when activation has been initiated
-
Activated: When a model is in this state, metrics are now being collected, changes are not possible. An activated model supports an Export action using which you can export a model and import it into the application.
-
Failed: A model falls into this state when it encounters issues during activation
-
Deactivated: A model moves into this state when a change occurs in the underlying implementation or you deactivate it specifically.
-
System Deactivated: when the underlying integration application becomes deactivated/undeployed due to systemic errors such as composite getting deactivated due to loss of connectivity and retries exceeding threshold.
-
User Deactivated if you specifically deactivate the model.
-
2.6.2 Model Lifecycle Actions
You can execute the following actions on a model, depending on the current state of the model:
-
Activate: Activates a draft model. The model definition must be 100% complete to activate it. A draft can be activated to replace the existing active model.
-
Deactivate: Deactivates an activated model.
-
Delete: Deletes an activated model. This action is permanent and cannot be reversed.
-
Create Draft: Creates a draft of an active model. You can edit the draft without affecting the active model.
-
Discard: Discards a draft model. This action is permanent and cannot be reversed. Note that this action is applicable only to a draft model.
2.6.3 Impact of Reactivation of Model After Changes in Model Metadata
If you change the metadata of an activated model and try to activate it again, the existing metrics of the model are impacted.
The following table illustrates the impact on the existing metrics of the model being reactivated.
Table 2-1 Impact on Existing Metrics
| S. No. | Model Metadata Area | Operation | Details | Impact on existing metrics collected |
|---|---|---|---|---|
| 1 | Business Model | Business Model Name Change | Model name changed in the application UI | The model name is changed across the application and there is no impact on the existing metrics. |
| 2 | Milestone mapping | Milestone added | A new milestone gets added | New instances created after activation will start collecting data for the new milestone. Existing metrics will remain unaffected. |
| 3 | Milestone mapping | Milestone deleted | A milestone gets removed |
Existing metrics collected for the deleted milestone will be lost. Existing instances will depict that the milestone was never reached. You will also be notified with a warning message about such changes upon re-activation of the model. |
| 4 | Milestone mapping |
Milestone type modified |
Milestone type is modified. The type can be any of the following:
|
The existing metrics may become confusing as the milestone type is being changed. Suppose a milestone which was terminal is changed to Standard. The milestone details page for existing instances will not show any terminal milestone. You will also be notified with a warning message about such changes. |
| 5 | Milestone mapping |
Milestone name modified |
The milestone name is modified | No impact on existing metrics. All consoles will show the changed name. |
| 6 | Milestone mapping | Milestone implementation mapping changed | The milestone implementation mapping locator is changed | No impact on existing metrics. New instances will collect data in accordance to new implementation mapping. |
| 7 | Indicator mapping | Indicator added | A new indicator has been added | No impact on existing metrics. New instances will start collecting metrics for new indicator upon re-activation of the model. |
| 8 | Indicator mapping | Indicator deleted |
The existing indicator is deleted |
The existing metrics collected for the deleted indicator will be lost . On activating the model with a deleted indicator , you will be presented with a list of consoles where the indicator is being used . You must remove such consoles or remove the usage of the indicator from those consoles to proceed with the activation. |
| 9 | Indicator mapping | Indicator Extraction criteria is modified | Indicator extraction criteria is modified which results in data type of the indicator to be changed |
The existing metrics collected for the indicator will be lost. On activating the model with a deleted indicator, you will be presented with a list of consoles where the indicator is being used. You must remove such consoles or remove the usage of the indicator from those consoles to proceed with the activation. |
| 10 | Indicator mapping | Indicator Name is modified | The indicator name is modified | No impact on existing metrics. The new indicator name will continue to show for existing and new instances. |
2.7 Effect of SOA/Service Bus Transactions
The capture of milestones and business indicators are intricately related to the transaction semantics in the SOA composite or the Service Bus on which the Insight model is based. Insight captures milestones only when they have reached/passed, which means only when the SOA/Service Bus transaction was committed. However, if a milestone is configured as an error milestone, it is captured even when the transaction is rolled back, because in this case the user is explicitly looking for error. The following table summarizes various scenarios:
Table 2-2 Transaction Behavior
| Type of Milestone | On Rollback |
|---|---|
|
Initial |
Milestone is NOT captured |
|
Standard |
Milestone is NOT captured |
|
Error |
Milestone is captured |
|
Terminal |
Milestone is NOT captured |
|
Terminal and Error |
Milestone is captured |