2 Designing a Model

This chapter describes the components of your model and how to map and activate the model.

2.1 Overview

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 describes the high-level concepts associated with an application, whereas the architect refines those concepts and maps them to an application implementation. These personas are encapsulated using roles that are shipped with Insight. Your administrator assigns you to the appropriate role(s) based on how you will use the product.

Every model includes:

  • Basic metadata

    For more information see Model Metadata in the Understanding Oracle Real-Time Integration Business Insight.

  • Milestones and associated indicators

    For more information see Milestones and Indicators in the Understanding Oracle Real-Time Integration Business Insight.

  • Unique Instance Identifier

    For more information, see Unique Instance Identifier in the Understanding Oracle Real-Time Integration Business Insight.

2.2 Modeling Your Business Application

This section describes how to create your model, define milestones, and create indicators.

2.2.1 Creating Your Model

Work on models is done using the Model Designer. When you open the Model Designer and click the Create Model button, you create a new model in Draft state.

Only drafts of models can be edited. When a new model is created, it is by definition a draft, but you can also create drafts of models that are already activated (see Activating Your Model for more information on what “activated” means). This allows you to modify drafts of models that are active without affecting the actual active model.

Figure 2-2 Model Actions Menu

Description of Figure 2-2 follows
Description of "Figure 2-2 Model Actions Menu"

Once all changes to a draft are finalized, you activate the draft. This pushes a new model (or changes to an existing model) out to the system and triggers the collection of metrics that conform to the model.

Every model includes some basic descriptive metadata, including:

  • Name

  • Icon

  • Description

  • Single Instance Label

  • Multiple Instance Label

Of these fields, only the model name is required. For details on all basic project metadata, see Creating a Model in Using Oracle Real-Time Integration Business Insight

2.2.2 Milestones

After you create a model, the next step is to create milestones for the model. You create a new milestone by clicking the Create Milestone button in the Designer.

Milestones are a key abstraction in an application model. They are points in an 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. An architect then refines the milestones and maps them to appropriate points in the application implementation (see Mapping Your Model to Your Application for details on mapping).

There are several different types of milestones, including Initial, Standard, Error, Terminal, and Terminal/Error. Every model is required to have at least one Initial Milestone, and at least one Terminal Milestone.

Initial Milestones are special because once passed, the process instance with which they are associated is assumed to be valid. This concept is key to filtering out instances that may already be in flight when Insight starts monitoring a runtime engine. An instance that has passed an Initial Milestone at least once is considered “Active”.

A Terminal Milestone is important as well, because it represents an expected end to the instance associated with the business model. Once a Terminal Milestone is passed, the instance is no longer active. For example, a milestone representing the completion of an order, "Order Complete" might be modeled as a Terminal Milestone.

See Types of Milestones in Understanding Oracle Real-Time Integration Business Insight for details on the different types of milestones and their semantics.

Notice the task hint depicted as an orange bubble next to the milestone name. As you work with a model, the designer provides guidance on the remaining tasks required to successfully complete the definition of the model. Hovering over the task hint shows a description of what needs to be done to complete the task.

In this example, the newly created milestone has not been mapped to an implementation artifact (such as a SOA composite service or Service Bus pipeline). Once you create the mapping, the task hint will no longer be shown.

Figure 2-6 Missing implementation Mapping

Description of Figure 2-6 follows
Description of "Figure 2-6 Missing implementation Mapping"

2.2.3 Indicators

In addition to Milestones, Indicators can also be defined for a model. Indicator values are extracted from application messages when milestones are passed. For example if indicators have been associated with a milestone that is mapped to a service invocation, when that associated service is invoked, the indicators will be extracted.

Indicators allow business users to gain insight into the proper functioning of the application, and also allow comparisons between application instances.

There are two types of indicators: Measures and Dimensions.

Measures identify values, which allow the state of the application to be quantified. A single measure can change over the lifecycle of an instance. For example, a typical order application might define measures for Total Order Value or Item Count.

Dimensions, on the other hand, provide a type of grouping and categorization of instances, allowing for slicing and dicing of aggregate measures. For example, a typical order application might define dimensions for Geographic Region, Sales Channel, or Product Category.

You create indicators for a milestone in the Milestones tab of the model editor.

Once you add an indicator to a milestone, you must define the indicator by selecting a name, and specifying whether the indicator is filterable (can be used as filter criteria for finding instances in the console).

An architect defines extraction criteria for the indicator (see Extracting Indicators), as indicated by the task hint next to the indicator’s name.

2.2.4 Unique Instance Identifier

You must define exactly one unique instance identifier for every Insight model . The identifier guarantees uniqueness among all instances of the process. 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 identifier for an instance.

For example, you might choose IncidentID as a unique instance identifier for a help desk application. You would not want to use something like user badge number, because the same user can submit more than one incident.

2.3 Mapping Your Model to Your Application

Once a business user has defined the abstract model for a business application using milestones and indicators, it is then up to the architect to map these abstractions to concrete implementation artifacts.

Mapping milestones involves identifying execution points that best represent when a milestone has been passed. You can map milestones to a number of different technologies including SOA services, references, and components, as well as Service Bus pipelines and business services.

For example, an architect might determine that invocation of a service called placeOrder best represents passage of a milestone called OrderReceived.

You must also define extraction criteria for indicators, as part of the mapping process. Extraction criteria defines the rules that the system uses to extract information from runtime messages, and is expressed using XPath expressions.

2.3.1 Mapping Milestones

Architects use the Designer to modify a draft model that has been defined by a business user. Insight provides additional UI controls that allow the architect role to create mappings for each milestone.

Creation of a new mapping involves the architect first choosing a data connection. Data connections provide a view into the deployed projects on a functioning runtime engine, either Oracle SOA Suite or Oracle Service Bus. The Insight administrator creates and maintains the data connections.

Different types of data connections show different types of artifacts. For example, if you’re mapping a milestone to a SOA composite service, choose an available SOA data connection, and then browse the list of deployed composites to find the service that best corresponds to the milestone.

Service Bus data connections show a list of Oracle Service Bus projects.

For both Oracle SOA Suite and Oracle Service Bus, only artifacts to which Insight supports mapping are listed for the architect. See Mapping Milestone to an Implementation in the Using Oracle Real-Time Integration Business Insight for details on what kinds of technologies and artifacts are supported for mapping milestones.

The architect identifies a SOA connection and a SOA composite and then drills down to a specific service or reference using a graphical composite browser.

The composite browser can then be used to select a specific composite or component service/reference to which to map the milestone. The specific operation and interaction type must also be specified.

Figure 2-12 Implementation Mapping

Description of Figure 2-12 follows
Description of "Figure 2-12 Implementation Mapping"

2.3.2 Extracting Indicators

Similar to milestone mapping, architects must also specify extraction criteria for indicators. The extraction criteria define the rules (in the form of an XPath expression) for pulling business data off a runtime message at the point that a milestone is passed.

The extraction criteria tooling automatically uses the schema of the service to which the indicator’s milestone is mapped. You can drill down into the message shape, in addition to using a variety of XPath functions.

Figure 2-14 Expression Builder

Description of Figure 2-14 follows
Description of "Figure 2-14 Expression Builder"

2.4 Activating Your Model

After a model has been defined by the business user, and then mapped by an architect, you activate the model.

2.4.1 What Happens When Your Model is Activated

Activating a model pushes the model definition, including mapping metadata, out to the runtime engines used during the mapping process. Mapping metadata is used by the runtime engines to monitor for execution patterns indicating that milestones have been passed.

The process of validating a model, distributing it to the runtime engines, and then beginning the process of active monitoring for extracting metrics takes some time to complete.

While the activation is occurring, you see a progress dialog tracking the activation of the model.

Figure 2-15 Activation In Progress

Description of Figure 2-15 follows
Description of "Figure 2-15 Activation In Progress"

For more details on activating a model, see Activating a Model in Using Oracle Real-Time Integration Business Insight.