Insight Server

Decision Server Insights is designed for scalability, high availability, and does not require shutdown during product or system update.

Scripts are provided for all server management tasks, including creating servers from a template, deploying solutions, managing connectivity, and disaster recovery.

The installer provides the following server templates:

Note: The Decision Server Insights installer provides a sample server, which is intended to help you get up and running as quickly as possible. The Insight Server run time is based on WebSphere Liberty profile. The data grid is based on IBM® WebSphere eXtreme Scale (WXS). Decision Server Insights in production can be configured to write grid state to a database (which might in turn be replicated across data centers). A grid can be rapidly restored from a disaster recovery database.

You can set up multiple runtime servers to store your data in a number of partitions. You configure the number of servers that contain the grid data, and eXtreme Scale distributes the data into shards over these server instances. A catalog service locates the primary shard for each key. It handles moving shards among servers when the physical servers fail and later recover.

If you set up a multiple server topology, you must configure the runtime environment before you deploy the artifacts to the Insight Server. When the server is configured and started, export and deploy the agent features of your solution.

After you develop and deploy a Decision Server Insights solution, you can start to submit events into the server and see the effects on the agents it creates.

The following steps describe what happens when a message is sent from an endpoint that is defined in the description of a solution.

  1. Deployed agents listen for event types that are submitted into the server. An event is a message that includes an ID to uniquely identify the semantic content of that message. An event holds a transaction date and time, which is the real time of the real origin of that message.
  2. The event is routed to an agent by pairing the entity type that is described in the agents with the entity payload of the event. The agent describes how the event is processed.
  3. An entity ID extractor function maps the event to an entity ID.
  4. A map of the event and its routing agent is populated dynamically from introspection of the event when it arrives for routing.
  5. The routed event is placed in an event work queue.
  6. When the agent receives the event, the agent locates the target entity by using its ID, and executes the logic that defines how to process the event.

    The entities that are bound to the agent are kept in memory during its lifetime so that it can share the state with other agents, and external systems. The state of the entities can be accessed by using the REST API.

    The agent state is also persisted to evaluate its rules, but is not accessible outside of the instance. The state is garbage collected based on the semantics of the rules and the time windows that are defined in the rule conditions.

  7. Events that are emitted by an agent are sent to outbound endpoints according to the connectivity definitions of the solution.
  8. The runtime log is available in the OSGi console.