Fixed vs Mapped Messages

The Kamanja engine presents what is known as a message (or multiple messages) to each model designed to handle them. A fixed structure (represented as a Scala class instance at runtime) or a mapped message (represented as a Scala map [String, <some data type>] at runtime) represents the messages. Use fixed messages when all fields … Read More


Mapped messages: getOrElse function: getOrElse(keyName: String, defaultVal: Any): AnyRef The method returns the value if the record is found else returns the default value. Fixed messages: getorElse function: getOrElse(keyName: String, defaultVal: Any): AnyRef getOrElse(index: Int, defaultVal: Any): AnyRef The method returns the value if the record is found else returns the default value. Note: Don’t … Read More

Getting Native Field Names for the Output

A message can expose the getNativeKeyValues method that provides native field names and values. The purpose is to provide the same case field names of the message definition in the output. This method gets the field name (lower case of the message definition field name), field native name (same case as the message definition field … Read More

Input Messages

Adding the message definition uploads it in the form of a JSON file to Kamanja. The JSON file describes the structure/template of the message. Notice that the message definition is not the input message (message data). It is the definition of the input message. The input message can be CSV, JSON, XML, or KV (new in v1.2). The … Read More

kPMML – Messages Versus Containers

Note that the only distinction between a container and a message is one of convention. The only significant difference is that messages are cataloged globally in the metadata as top-level container structures. The message is the principal vehicle for presenting data to the model. Instead, use container instances as elements of a message or another … Read More

Mapped Messages

In the following section, remember that a mapped message definition is written in JSON, but the message data may be KV or JSON. To use mapped messages: 1. In the message definition, set Fixed:false to indicate a mapped message. 2. In the cluster configuration, under the Adapters section of the configuration, change the DataFormat to … Read More


A message is a structure that provides design-time definitions of incoming data and interfaces that makes it easy for Kamanja to process it in the flow at run-time. Simply put, the message defines the record structure, with field names and types in the order the fields appear.

Messages and Containers

Input Messages Click on the above link to learn about message definitions and input messages. Output Messages Click on the above link to learn about output messages. Containers Click on the above link to learn about containers. Concepts and Derived Concepts Click on the above link to learn about concepts. Types Click on the above … Read More

Nested Messages and Containers

A nested message or container cannot be defined. Create a separate container that must be referenced within the JSON as such:

Here is a message that contains several elements, including both fields and containers. The containers are where the nested message comes into play. The container must be referenced directly. See below for one … Read More

Output Messages

Downstream consumers may take any number of actions based on output messages received from Kamanja, including presenting them on a dashboard, generating alerts or triggers, passing them on to other applications for further processing, or simply storing them in a database for further review or analysis. Output Message Definition The Kamanja engine presents an output … Read More