Qorus Integration Engine® Enterprise Edition 6.0.25_prod
|
Back to the Developer's Guide Table of Contents
All Qorus integration objects are described by YAML metadata produced by our IDE, which is available as a free (as in free of charge and also open source) extension to Microsoft Visual Studio Code, a multi-platform editor from Microsoft. The Qorus extension is called Qorus Developer Tools and can be installed directly from Visual Studio Code.
Class definition files containing YAML metadata and a reference to the source code file are used to create class objects in the Qorus schema that can then be used by other integration objects, such as workflows, services, jobs, mappers, or even other class objects.
Class objects are the fundamental building block element of Qorus; they allow their code to be instrumented with configuration that should be designed to make them generically useful for many different use cases, and enable changes to be made with configuration rather than coding.
Class definition files are parsed by the oload program, which will create class objects in the Qorus database according to the definitions in the file.
Classes have the following attributes:
The name of the class; the name and version together are unique identifiers for the class and are used to derive the classid (the single unique identifier for the class; it is generated from a database sequence when the class is loaded into the system via oload).
Multiple classes with the same name and different versions can exist in the system at the same time. Classes are referred to with their classid, which is derived from the name and version together (except in Library Objects, where the latest version of the class is used which is determined by the last creation date of the class object in the database, and not with a comparison of the version strings).
The version string for the class object; the name and version together are unique identifiers for the class and are used to derive the classid (the single unique identifier for the class; it is generated from a database sequence when the class is loaded into the system via oload).
name
but different version
values are different objectsA string "patch" label which can be used to show that a class was updated while not affecting the classid.
patch
value can be updated without affecting references to other objects; the unique ID for the object is not updated when the patch
value is updatedA description for the class; the description field supports markdown for formatted output in the UI and IDE.
The "author"
value indicates the author of the class and will be returned with the class metadata in the REST API and also is displayed in the system UI.
The programming language for the class's source code; can be one of:
python
java
qore
The source code for the class implementation; must be in the programming language specified by Class Language
The source can use other source code; see Class Dependencies
An optional list of classes that the class depends on; these other classes are also loaded into the interface's logic container when the class is listed as a dependency; in this way a single class can encapsulate multiple class object dependencies, which can simplify dependency management for complex class hierarchies and in interconnected code.
Configuration items are metadata describing configurable parameters that should define how the code of the class is executed at runtime.
Configuration items have a name, a description (supporting markdown), a data type, and other attributes.
Configuration item values can be set at three levels, the global level, the workflow level, and the configuration item level. The value used is the lowest-level value set.
The runtime value of a configuration item can be retrieved with the APIs in the following table:
Configuration Item Value APIs
API Type | API | Description |
Python | wfapi.getConfigItemValue() | retrieves a single configuration item value |
Python | wfapi.getConfigItemHash() | retrieves all configuration items |
Java | WorkflowApi.getConfigItemValue() | retrieves a single configuration item value |
Java | WorkflowApi.getConfigItemHash() | retrieves all configuration items |
Qore | WorkflowApi::getConfigItemValue() | retrieves a single configuration item value |
Qore | WorkflowApi::getConfigItemHash() | retrieves all configuration items |
Class connectors are defined in class metadata and enable the class to be connected to other classes. They can also declare input and output data types to ensure type-safe processing when processing data as well.
Class connectors have the following attributes:
Class Connector Attributes
Key | Mand.? | Description |
name | Y | The name of the connector; this name will be used when choosing the connector |
method | Y | The name of the class method that will be called; this must correspond to a real method in the class |
type | Y | The type of connector; describes how the connector can be used |
input type | N | The input data type for the connector |
output type | N | The output data type for the connector |
The name of the connector used when choosing the connector in the IDE or displaying it in the UI.
The connector name is stored in the YAML and is used to reference the connector in other objects.
The name of the class method that will be called; must correspond to a real method in the class.
Connector Type | Description |
event | Event-based connectors provide an event source and can only be used in services |
input | Input connectors can be connected to a preceding connector in a chain but provide no output data and cannot have any further connectors after them |
output | Output connectors do not accept any input data and must be the first connector in a chain, as they cannot be connected to a previous connector. They can produce output data. |
input-output | A generic connector that can be connected anywhere in a chain |
condition | A connector that returns a boolean value, meant to be used as the logic in a state transition in a finite state machine |
When the event must be raised, call the appropriate method as follows:
Input connectors can be connected to a preceding connector in a chain but provide no output data and cannot have any further connectors after them.
An input connector must be the last connector in a chain.
Input connectors may ignore their input data.
Output connectors do not accept any input data and must be the first connector in a chain, as they cannot be connected to a previous connector. They can (but do not necessarily have to) produce output data.
When a class declares processor compatibility, it allows the class object to be used in a data pipeline.
In this case, the class must inherit one of the following classes depending on the source language:
Class processors can be used to filter, generate, or transform input records in a data pipeline and can also declare their input and output record types to ensure that type safety is enforced in the pipeline.
Library objects are code objects that are refenced by name only (meaning no version or ID) from other objects, to be loaded in to the target interface object's program container to provide additional code and configuration.
The primary type of library object is the class. Also supported for backwards compatibility are constant and function objects.
If mutiple versions of a library object are present in the system, then the last version of the object is used in interfaces that require it, whereas the last version is determined by the most recent creation date of the object in the database; no version comparison is performed.
Queues provide the storage and delivery mechanism by which the results of executing an asynchronous event for an asynchronous step are delivered to the right step instance.
If a workflow has at least one asynchronous step, a queue must be defined. A single queue can be used for any number of asynchronous steps, however the keys in a queue must be unique. See the step queue attribute for more information.
When an asynchronous queue entry is updated, processing continues for the affected orders; at that time the updated queue data is sent to the waiting step's back end logic for further processing.
Queue entries for specific waiting asynchronous steps can be updated with the following APIs:
Interface group files provide the metadata for an interface group.
These groups can then be referenced by interface objects who can claim to be members of the group.
Workflow synchronization event objects are required for workflow synchronization event steps.