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:
- A single-server template that is named cisDev to configure a development server.
- A set of server templates to configure a multiple server topology
that is intended for high availability testing purposes and production.
- A WebSphere® eXtreme Scale catalog server template named cisCatalog: Coordinates eXtreme Scale containers.
- A WebSphere eXtreme Scale container server template named cisContainer: Stores entities and system information, and runs agents and analytics jobs.
- Inbound server template named cisInbound: Submits events to the grid by using the gateway API over HTTP or JMS.
- Outbound server template named cisOutbound: Emits events from outbound maps over HTTP or JMS.
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.
- 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.
- 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.
- An entity ID extractor function maps the event to an entity ID.
- A map of the event and its routing agent is populated dynamically from introspection of the event when it arrives for routing.
- The routed event is placed in an event work queue.
- 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.
- Events that are emitted by an agent are sent to outbound endpoints according to the connectivity definitions of the solution.
- The runtime log is available in the OSGi console.