nJAMS Glossary#
- Publication:
Nov 08, 2024
A - B - C - D - E - F - G - H - I - J - K - L - M - N - O - P - Q - R - S - T - U - V - W - X - Y - Z
A#
agent#
nJAMS Agent is the nJAMS component that collects Metrics and provides them to nJAMS Argos. The configuration of input and output plugins specifies what kind of data the nJAMS Agent is collecting, and how it is sent to nJAMS Server.
argos#
nJAMS Argos provides visibility of applications and infrastructure and acts as a component within nJAMS Server and nJAMS Cloud. Argos completes the view on processes with Metrics from application and infrastructure monitoring. Argos is supplied with Metrics from nJAMS Agent.
attribute#
An Attribute in context of nJAMS represents a name/value pair of additional information that can be passed within a Log Event. Attributes are usually used to add functional information to technical Log Events, such as order id or customer name. Attributes allow you to search for Log Entries by a particular business related information. In contrast to Business Object and Business Service, Attributes are not fixed to their meaning, but can be freely defined. Attributes are determined by an Extract or by using nJAMS Log Activities. Attribute pairs appear on a Tile of the Result List.
Refer to: log activity, extract, log event, tile, result list, business object, business service
B#
business object#
In context of nJAMS, a Business Object is a label for a Log Entry. This label allows to retrieve the Log Entry in nJAMS GUI using the name of the corresponding Business Object. Business Objects are arranged in the Tree. A hierarchy of Business Objects is possible. A Business Object is determined by an Extract or by using nJAMS Log Activities. A Business Object could be: order, creditor, debtor, product, etc. For example, when you select Business Object order from the Business Object Tree in nJAMS GUI, you will get a list of Log Entries that are tagged with order.
Refer to: tree, business service, extract, log activity, log entry
business service#
A Business Service in nJAMS represents a label for a Log Entry. This label allows to retrieve the Log Entry in nJAMS GUI using the name of the corresponding Business Service. Business Services are arranged in the Tree. A hierarchy of services is possible. A Business Service is determined by an Extract or by using nJAMS Log Activities. A Business Service could be: order service, invoice verification, credit check service, etc. For example, when you select Business Service invoice verification from the Business Service Tree in nJAMS GUI, you will get a list of Log Entries that are tagged with this service.
Refer to: tree, business object, extract, log activity, log entry
C#
client#
The nJAMS Client is the sensor that provides insight into Process Executions of the monitored system. There are individual nJAMS Clients providing unique capabilities to monitor various integration platforms and applications. An nJAMS Client is able to monitor each individual Process Execution and can correlate their transactions. nJAMS Client acts as a plug-in within the monitored system.
Refer to: cloud, server, process execution
cloud#
nJAMS Cloud represents an nJAMS offering that provides a subscription for an nJAMS Instance as a service. An nJAMS Cloud Instance is a fully managed service by Integration Matters. You only have to connect an nJAMS Client to your nJAMS Cloud Instance and you are ready to monitor your integration platform and get process insight of your applications.
compress successful transactions#
Compress Successful Transactions is a property of a Domain Object. This setting allows to discard monitoring information about the execution path of successfully executed processes. Enabling this setting is an option to reduce the data volume stored by nJAMS.
Refer to: domain object
correlation#
In context of nJAMS, a Correlation stands for a series of correlated Log Entries. Correlated Log Entries are created, when Process Executions follow each other and are therefore interconnected. For example, assume “Process A” calls “Process B”. Processes “A” and “B” are connected, respectively correlated. nJAMS creates separate Log Entries for processes “A” and “B” and correlates the Log Entries automatically using a common unique Correlation Id.
Refer to: log entry, log id, correlation id, parent log id
correlation id#
The Correlation Id is a unique identifier for correlated Log Entries.
Refer to: log entry, correlation, log id, parent log id
D#
data provider#
A Data Provider is a component in nJAMS Server that receives and processes incoming Log Messages sent by nJAMS Client. The Data Provider is basically feeding data into nJAMS Server. In addition, the Data Provider can also receive and process messages containing Metrics from nJAMS Agent. The Data Provider requires a connection to a JMS Provider.
Refer to: log message, jms provider, indexer, tracing, replay, metrics, agent
data retention#
Data Retention determines the duration of storing data in nJAMS. Basically all data in nJAMS is expiring. You can change the expiration of data by configuring Data Retention for Domain Objects, Metrics, notifications, etc.
Refer to: domain object, metrics, notification center
domain object#
A Domain Object represents a technical category of the monitored system, such as domain, application, process, etc. Domain Objects are usually organized in a hierarchical structure and are arranged in tree view in nJAMS GUI. The properties of Domain Objects can be configured, for example, to determine the duration of Data Retention. You can also grant permissions to Domain Objects in order to restrict access to Log Entries per Domain Object.
Refer to: tree, domain object path
domain object path#
The Domain Object Path is the complete path of a Domain Object, from the root to the selected element. Similar to a folder structure, Domain Objects are arranged hierarchically. The individual elements in the path are separated by character “>”.
A Domain Object Path looks like this, for example:
>fs_endurance>OrderServices>OrderServices-Orchestration>OrderServices/OrderConfirmation/Starter_OrderConfirmationService.process>
This is an example, where the Domain Object Path only consists of the root element:
>my_domain>
Refer to: tree, domain object
E#
elasticsearch#
Elasticsearch, respectively elastic, is the storage system used by nJAMS for persisting data like Log Messages, Metrics, statistics, etc. Though actually an indexing system, nJAMS uses Elasticsearch as datastore also. Elastic is actually the vendor company of Elasticsearch, but this term is also often used as short form for Elasticsearch. See also: https://www.elasticsearch.com
Refer to: log message, metrics
engine#
Engine refers to the execution unit of the monitored system, where applications and processes are executed. An Engine can be represented by a JVM or another runtime environment. |TIBBW| or |MULERUNTIME| are examples of integration platforms whose execution units we refer to as Engines.
Refer to: process execution
event#
An Event is used as a synonym for Log Event.
Refer to: log event
event list#
The Event List represents the list of Log Events of a Log Entry in nJAMS GUI.
Refer to: log event, log message, project message
event status#
In context of nJAMS, the Event Status represents the Severity level of a Log Event.
The Event Status can consist of the following Severity levels: info, success, warning, error.
The Status of a Log Entry is in turn calculated from a sequence of Event Statuses.
explicit logging#
Explicit Logging complements Implicit Logging with explicit Log Events.
nJAMS Client can create additional Log Events by using an Extract or by using nJAMS Log Activities.
A Log Event is also created explicitly, when an activity is executed that has Tracing enabled.
Explicit Logging is used in combination with Implicit Logging, when Log Mode is complete (default).
Explicit Logging is used exclusively, when Log Mode is exclusive.
When Explicit Logging is used exclusively, nJAMS Client will only monitor Process Executions, where a Log Event has been created explicitly.
Refer to: implicit logging, log event, log mode, process execution, extract, log activity
extract#
An Extract allows you to create nJAMS Log Events on any activity regarding a process definition of the monitored system. The Extract definition takes place Non-Invasively at runtime, which means Log Events can be added or removed at any time during runtime without modifying the process design model.
Refer to: log event, log activity, invasively, process definition
F#
flows#
IM Flows represents an nJAMS extension that allows to create a model of your business flow. The flow model is based on rules that evaluate incoming Log Events from monitored Process Executions. Flows acts as a meta layer above the process implementation. With IM Flows you can benchmark the execution of your business flows in various ways.
A second meaning of Flows is related to the Mule integration platform. MuleSoft™ applications are made up of flows. Flows in context of Mule is similar to the meaning of processes in TIBCO ActiveMatrix BusinessWorks™, another integration platform monitored by nJAMS.
Refer to: flows instance, log event
flows instance#
A Flows Instance represents the execution of a IM Flows model. A Flows Instance runs within nJAMS Server. A Flows Instance is started rule-based on incoming Events.
Refer to: flows
G#
gui#
nJAMS provides a graphical user interface (gui) to search for Log Entries and visualize monitor data in various ways. nJAMS GUI is part of an nJAMS Instance and available by using common web browsers. Furthermore, nJAMS GUI allows to manage your nJAMS Instance, such as user administration, authorization assignment, control message processing, etc.
H#
hub#
nJAMS Hub stands for the central web portal to manage your nJAMS account at Integration Matters. Once you logged in into your account, you can use nJAMS Hub to enter your nJAMS Cloud Instances, get your Instance key to connect nJAMS Client against your nJAMS Cloud Instance, invite additional users to work with your Instances and update your organization. nJAMS Hub is available at: https://hub.integrationmatters.com/
I#
implicit logging#
In nJAMS Implicit Logging means nJAMS Client is automatically collecting Events of a Process Execution once it is enabled.
When Implicit Logging is on, you do not have to worry about creating Log Events at certain places of your process.
nJAMS Client automatically detects, when a process has started and ended.
If errors occur during execution, they are also detected and logged automatically.
Implicit Logging is enabled, when Log Mode is complete (default).
Implicit Logging is turned off, when Log Mode is exclusive.
In this case, nJAMS Client exclusively uses Explicit Logging.
Refer to: explicit logging, log mode, log event, process execution
index#
An Index is the coarsest unit in Elasticsearch for structuring data. nJAMS organizes its data into separate Indexes by type of data (e.g. monitor data, statistics, Metrics, etc.), and each Index type again utilizes multiple Indexes according to Data Retention. Each nJAMS Index contains an expiration date. The data is stored into the Index of the corresponding type with the expiration date that best reflects the actual data storage. Depending on the expected data volume, Indexes are created on a daily, weekly or monthly basis.
Refer to: index, elasticsearch, data retention
indexer#
The Indexer client is the component in nJAMS Server that connects to the persistent storage system and is responsible for storing and retrieving data. nJAMS Server uses Elasticsearch as data storage technology. When the Indexer client is stopped, neither new data can be stored, nor existing data can be retrieved from the storage system, i.e. the entire message processing is stopped.
Refer to: log message, data provider, index
instance#
An nJAMS Instance is the central unit for receiving, processing, and storing Log Messages. In addition, the nJAMS Instance provides a graphical user interface (gui) to allow searching for Log Entries and presenting the search results. The nJAMS Instance is provided by an on-premise nJAMS Server installation, or by a managed service via an nJAMS Cloud subscription.
See also: server, cloud, gui, log message
invasively#
In context of nJAMS, Invasively stands for a monitoring mode, where the process model needs to be modified in order to initialize and use nJAMS Client. In other words, when you decide to use nJAMS Log Activities within your process design, you are monitoring your applications invasively. By default, nJAMS Client is used Non-Invasively.
Refer to: non-invasively
J#
jms provider#
A JMS Provider is a messaging system that implements the JMS interfaces and provides administrative and control features. nJAMS Server and nJAMS Client use the JMS Provider for communication. Popular JMS providers supported by nJAMS are TIBCO Enterprise Message Service™ and ActiveMQ. nJAMS Cloud does NOT use JMS for communication with nJAMS Client, instead nJAMS Cloud uses secure transport communication via TLS/HTTPS.
Refer to: data provider
job#
A Job is a synonym for Process Execution.
Refer to: process execution
K#
L#
log activity#
nJAMS Log Activities are used at design time and can be placed anywhere between start and end of a process model of the monitored application. Similar to Extracts, nJAMS Log Activities are used to send Log Events. Since nJAMS Log Activities are used at design time, they are part of the process design and are therefore always available in any environment, where the application is deployed. At present, Log Activities are available for nJAMS Client for BW and nJAMS Client for BW6.
log entry#
In nJAMS a Log Entry is the representation of a Process Execution. Each Log Entry has a unique Log Id and is represented by an entry in the Result List of nJAMS GUI. A Log Entry contains several information regarding a Process Execution, such as start/end time, duration, Status, Process Execution Path, etc. A Log Entry can contain additional associated Log Events. Log entry is a synonym for Main Entry.
Refer to: log event, process execution, result list, status, process execution path
log event#
A Log Event represents an Event that is triggered while monitoring a Process Execution. A Log Event is sent via an Event Message. A Log Event has an Event Status and can contain a number of additional information, such as Payload, Stacktrace, Attributes, etc. A Log Event is triggered implicitly by nJAMS Client, if an unhandled exception occurs. Furthermore, additional Log Events can be triggered explicitly from any activity during a Process Execution by using an Extract or by using nJAMS Log Activities.
See also: event status, payload, stacktrace, attribute, process execution, extract, log activity
log id#
A Log Id is a unique identifier for a Log Entry.
Refer to: log entry, correlation id, parent log id
log message#
A Log Message carries information about Log Events monitored by nJAMS Client. A Log Message is sent from nJAMS Client to nJAMS Server, respectively nJAMS Cloud.
Refer to: log event, project message, message format
log level#
The term Log Level is used in nJAMS to determine the Severity of a Log Event to be passed to an nJAMS Instance.
The Log Level can be configured for a Domain Object at process level.
For example, you may want to avoid the clutter of successful Log Entries related to a Process Execution, where you are only interested in things that went wrong.
To do this, you can configure the Log Level for the Domain Object of this process to warning.
nJAMS Client will then only send Log Events with Status of Severity warning or higher.
Refer to: status, severity, log event, domain object, log mode
log mode#
In context of nJAMS, Log Mode determines the basic functionality of an nJAMS Client and affects the monitoring of the entire Engine.
When Log Mode is complete, nJAMS Client is fully enabled, which is the default setting.
Log mode none disables the client and thus turns off monitoring of the Engine entirely.
You can configure Log Mode to exclusive, if you only want to monitor Process Executions of the Engine, when an activity is executed that explicitly creates a Log Event, or has Tracing enabled, or was applied with an Extract.
In other words, Log Mode exclusive disables implicit logging by exclusively using Explicit Logging.
This monitoring mode is commonly used, if you want to reduce the amount of Log Entries, but still want to monitor Process Executions with relevance.
Refer to: implicit logging, explicit logging, engine, log level
M#
main entry#
In context of nJAMS, a Main Entry is the representation of a Process Execution. Main entry is a synonym for Log Entry.
Refer to: log entry, process execution
main list#
Main List represents the list of results after performing a search in Main View of nJAMS GUI. Main list is a synonym for Result List.
Refer to: result list, main view
main view#
Main View is the main page of nJAMS GUI. From this page you can search for Log Entries in various ways and view the search results and details.
Refer to: result list, log entry
message format#
The Message Format describes the format of a Log Message. The current Message Format (V4) is composed of a JSON structure, whereas the previous Message Format (V3) consists of an XML structure. Modern nJAMS Clients starting with version 4 send their information in V4 format. The V3 Message Format is deprecated.
Refer to: log message
metrics#
Metrics are data tracked over time. nJAMS Agent collects Metrics and sends them to nJAMS Argos.
monitored system#
The Monitored System represents the system that is monitored by nJAMS. nJAMS provides individual nJAMS Clients for various integration platforms and applications.
Refer to: client
N#
njams#
nJAMS is the product brand and stands for the short form of not Just Another Monitoring Solution.
non-invasively#
Using nJAMS Client Non-Invasively means, nJAMS Client monitors an application instantly without interfering and changing the process design. Running nJAMS Client Non-Invasively is the default monitoring mode. In contrast, you can use nJAMS Client Invasively by using nJAMS Log Activities.
Refer to: invasively, log activity
notification center#
The notification Center collects notifications issued by your nJAMS Instance. Here you can track, for example, when a Data Provider was last started, when a replay was triggered, or if there was a technical problem. The Notification Center can be accessed via the nJAMS GUI.
Refer to: gui
O#
P#
palette#
The nJAMS Palette is a set of nJAMS Log Activities that are used to send Log Events. nJAMS palette is an integral part of nJAMS Client for BW and nJAMS Client for BW6.
Refer to: log activity
parent log id#
The Parent Log iId is the unique Log Id of a correlated preceding Log Entry. Within a Correlation chain, a correlated Log Entry can have one single preceding Log Entry, but several subsequent Log Entries.
Refer to: correlation, correlation id, log id
payload#
Payload in context of nJAMS represents the passed data or message during a Process Execution. The Payload is of particular interest during a Process Execution. Very often one would like to monitor the incoming message as well as the transformation of the message during the Process Execution.
Refer to: process execution
process definition#
Process Definition represents the design of a process model of the monitored system. Process Design and Process Model are used as a synonym for Process Definition.
Refer to: process diagram
process design#
Process Design is a synonym for Process Definition.
Refer to: process definition
process diagram#
A Process Diagram is the graphical representation of a Process Model in nJAMS GUI. Depending on the selection in nJAMS GUI, the Process Diagram either shows the Process Definition or the instantiated Process Model including the Process Execution Path. When you select a process entry in the Tree, the Process Diagram shows the Process Definition. Whereas when you select an entry from the Result List, the Process Diagram shows the Instance of the Process Model in the state at the time of execution.
Refer to: process definition, process execution, tree, result list
process execution#
Process Execution stands for the execution of a process model. When a process is executed, an Instance of the process model is created. An instantiated process model gets an id, the Job id, from the Engine that runs the process Instance. In nJAMS each Process Execution is represented by a corresponding Log Entry. Connected Process Executions are represented by correlated Log Entries. Process execution is a synonym for Process Instance.
Refer to: process instance, engine, job, log entry
process execution path#
The Process Execution Path describes the path that was taken during a Process Execution. The Process Execution Path is indicated in the Process Diagram by green colored transitions between activities and by a green badge at the executed activities.
Refer to: process diagram, track
process instance#
The Process Instance is the instantiation of a Process Definition. Process Instance is used as a synonym for Process Execution.
Refer to: process execution, process definition
process model#
Process Model is a synonym for Process Definition.
Refer to: process definition
project message#
A Project Message carries information about Process Definition and configuration of the monitored system. When the monitored system is starting up, a Project Message is sent from nJAMS Client to nJAMS Server, respectively to nJAMS Cloud
Refer to: log message, process definition
Q#
query#
With a Query you can perform complex searches for Log Entries. Multiple search terms can be combined with operators. A full text search is also possible. The Query is available in the nJAMS GUI and complements the simple search elements of nJAMS GUI.
R#
recording#
In context of nJAMS, Recording stands for saving the input data of a start activity during a Process Execution. The Recorded Data is used by nJAMS Replay to retrigger a Process Execution using the previously saved input data. Recording can be switched on/off per Engine or per individual process.
Refer to: recorded data, replay
recorded data#
Recorded Data represents the saved data of an input activity during a Process Execution. The Recorded Data is used by nJAMS Replay to retrigger a Process Execution using the previously saved input data.
replay#
nJAMS Replay extends nJAMS monitoring capabilities with the ability to launch Process Executions within a monitored application. Retriggering a Process Execution based on the original or modified input data is called Replay. Any replayed Process Instance is audited, i.e. you can track who started a Replay at what time. Using Replay can be restricted by certain permissions.
Refer to: recording, process execution
result list#
The Result List represents the list of hits after performing a search in Main View of nJAMS GUI. The Result List contains Log Entries of corresponding Process Executions according to specified search criteria. An entry in the Result List on Main View of nJAMS GUI is called a Tile.
Refer to: tile, process execution, main view
S#
sdk#
The nJAMS software development kit (SDK) is the fundamental basis for all common nJAMS Clients and allows developing additional nJAMS Clients for further integration platforms or applications that should be monitored by nJAMS. The SDK provides the general functionality for nJAMS Clients, such as communication with nJAMS Server.
Refer to: client
server#
The installation of nJAMS Server provides an on-premise Instance of nJAMS. In contrast to nJAMS Cloud the nJAMS Server runs in customer’s data center or private cloud. An nJAMS Server Instance is based on WildFly application server and uses an Elasticsearch cluster for persisting monitor data and a JMS Provider for communication with nJAMS Client.
Refer to: instance, cloud, jms provider
severity#
The term Severity is used in nJAMS to determine the highest Severity of a sequence of Event Statuses.
The Severity can consist of the following Severity levels: warning, error.
For example, assume a Process Execution creates two Log Events, one of Severity level info, one of error.
The actual Severity of the Process Execution, respectively the corresponding Log Entry, is then calculated with error, because error is the highest Severity level of both Log Events.
In combination with Status you can then evaluate the overall success of the Process Execution.
For example, if Status is success, but Severity shows error, you know the overall execution of the process was successful even though there were errors during execution.
Refer to: status, log entry, event status, log event, process execution
stacktrace#
The Stacktrace is part of a Log Event and contains information about the technical error during a Process Execution. The Stacktrace is provided by nJAMS Client implicitly, in case the error of a failing activity is not captured. If an exception handling is in place, you have the choice to explicitly log an Event including the Stacktrace.
status#
In nJAMS the Status represents the Severity of a Log Entry.
The Status can consist of the following Severity levels: success, warning, error.
The Status is calculated by a sequence of Event Statuses.
Refer to: log entry, event status
subagent#
A Subagent is a built-in agent in nJAMS Client. The Subagent collects metric data from the monitored system and forwards the Metrics to nJAMS Agent.
T#
tile#
A Tile represents a Log Entry in the Result List of nJAMS GUI and contains information about a Process Execution. Another meaning of Tile is used in context of custom reports, where a Tile represents the area for a chart type.
Refer to: result list, process execution, log entry
trace point#
The term Trace Point is used in nJAMS for enabled Tracing on a particular activity.
Refer to: tracing
tracing#
In the world of nJAMS, Tracing means to collect additional logging information with regards to an activity during a Process Execution. Tracing has to be enabled specifically for an activity. By default, Tracing is disabled. When Tracing is turned on, nJAMS collects data of the input and output structure of an activity while the process is executed. Tracing is often used for testing purposes or for analyzing data quality issues in production.
Refer to: trace point
track#
In context of nJAMS, Track is used as a synonym for Process Execution Path. The Process Execution Path is indicated in the process diagram by green colored transitions between activities and by a green badge at the executed activities.
Refer to: process execution path, process diagram
tree#
The Tree is used in nJAMS GUI to navigate between Domain Objects. Since Domain Objects are organized hierarchically, the Tree is the ideal representation of Domain Objects. The Tree can be arranged vertically or horizontally. Clicking on an element of the Tree instantly triggers a search for Log Entries.
Refer to: domain object, log entry
U#
V#
W#
war file#
The WAR file format is an W**eb Application **AR**chive. The |SERVER| WAR file contains the |SERVER| application. The |SERVER| application is deployed on **WildFly Application Server.
wildfly#
WildFly is the application server that runs nJAMS Server.
Refer to: server