Orchestration Query Language: querying has never been so easy.
The Orchestration Query Language (OQL) is a new syntax that applies to REST API V2 and helps you monitoring your Workload Automation production plan environment. For more information about REST API V2, see Introducing REST API V2 topic in the Documentation.
Creating queries and retrieving items in your database is now quicker and easier than before thanks to the different intuitive OQL keywords at your service.
For more information, see Querying with the OQL syntax topic in the Documentation.
Use JSON Web Tokens to enhance your agent authentication standard.
A JSON Web Token (JWT) is a standardized, self-contained access token which makes it possible for two parties to securely exchange data. Authentication information, expiry time information, and other user-defined claims are digitally signed, so that no database queries are required and the session does not need to be stored on a server.
JWT is especially suited for authentication purposes. Its short messages can be encrypted and securely convey who the sender is and whether they have the necessary access rights. It is also very useful in REST applications, because it ensures stateless protocols, since the information for the authentication is sent with the request.
JWT ensures mutual authentication between master domain manager and dynamic agents. Using JWT is easier and more immediate than downloading and maintaining certificates and, in a containerized environment, you no longer need to configure the ingress controller for SSL passthrough. For more information about JWT on containers, see the Ingress controller section in Workload Automation Server topic in the Documentation.
For more information about configuring security and authentication, see Connection security overview topic in the Documentation.
To download the JWT on your dynamic agents at installation time, use the jwt parameter as explained in Agent installation parameters - twsinst script. You can also download the JWT at a later time as explained in Certificates download to dynamic agents - AgentCertificateDownloader script.
You can find some installation examples in Example installation commands
You can also revoke a JWT simply by deleting the workstation definition where the JWT is installed. For more information about deleting a scheduling object from the command line and Dynamic Workload Console, see Revoking and reissuing a JSON Web Token topic in the Documentation.
Ensure there are no misalignments in date and time in your network nor significant network delays because this might prevent JWT from working.
You can now install dynamic agents on IBM i with a user different from QSECOFR.
You can now use a user different from QSECOFR to install IBM i agents. In this case, the new allObjAuth parameter is required when running the twsinst command to indicate that the user has the required ALLOBJ authority. Ensure the user is existing and has ALLOBJ authorization. The agent is started after connecting to the system with the TWSUSER or the user defined at installation time.
When you upgrade or uninstall the agent, a check is performed to ensure you are using the same user that performed the installation. If you used allObjAuth parameter at installation time, specify it again when upgrading or uninstalling the agent.
The name of the user used to perform the installation is maintained in the TWA_DATA_DIR/installation/instInfo/instUser file.
For more information, see Installing agents on IBM i systems, Agent installation parameters on IBM i systems, Upgrading agents on IBM i systems, and Uninstalling Workload Automation Agent on IBM i systems topics in the Documentation.
New encryption method for increased security
Security is a major concern in today's interconnected world. Government organizations, financial institutions, healthcare providers, and insurance companies are just a few examples of the types of entities who are taking security seriously.
You can optionally encrypt the passwords that you will use while installing, upgrading, and managing Workload Automation. The secure command uses the AES method and prints the encrypted password to the screen or saves it to a file.
For more information, see Encrypting passwords (optional) and Optional password encryption - secure script topics in the Documentation.
Workload Automation REST API V2 to better integrate workload scheduling capabilities with external products and solutions.
A new version of REST APIs has been introduced to operate on the product from both User Interface and Command Line Interface.
The new features of REST API V2 are designed to make the user experience even smoother:
Enhanced filtering opportunities: according to how specific your query needs to be, you can decide whether to use planFilter, which is similar to conman syntax and offers the same filtering capabilities, or OQL syntax, which is simpler and allows ordering the results. You can also decide to use both of them, using planFilter for filtering and OQL for ordering.
Improved payloads for easier consumption: both the hierarchy and the structure of payloads have been revamped to improve their understanding and usage.
Introduction of efficient multi-item endpoints: each action can be performed by ID and by filter. In this way, you can decide whether to operate on a single item or on multiple items.
Use API Keys to authenticate a command line or application easily and quickly.
You can create both Personal and Service API Keys in the Dynamic Workload Console and easily assign them to either specific users or groups. A comprehensive API Keys monitoring tool gives you full control over every valid, expiring and expired API Key that have been associated with an engine. For more information, see Authenticating the command line client using API Keys topic in the Documentation.
You can use API Keys to authenticate the command line. You can use an API Key to get authenticated when you launch composer, conman, wappman, and ocli commands, instead of having to provide username and password as in previous versions.
To use the API Key with these commands, you need to have a specific set of authorizations defined in the security file, so that you can generate and retrieve the key from the Dynamic Workload Console. To find out the required authorizations, see Object type - file topic in the Documentation.
To generate the key from the Dynamic Workload Console, perform the steps listed in Authenticating the command line client using API Keys.
After generating the token, you can either specify it in the command line with the -jwt parameter, or add it in the useropts file.
For more information about adding JWT in the useropts file, see Setting user options topic in the Documentation.
For more information about using JWT with commands, see Running the composer program, Running the conman program, wappman command.
You can also use the API Key to authenticate the master domain manager when installing the agents. This authentication allows the product to download the JWT or the certificates to be used for secure communication between master domain manager and dynamic agents. If you provide the API Key (with the apikey parameter), you no longer need to specify username and password (wauser and wapassword parameters) as in previous versions.
For more information about using the API Key for authentication purposes, see Agent installation parameters - twsinst script, Certificates download to dynamic agents - AgentCertificateDownloader script and Example installation commands topics in the Documentation.
Ensure there are no misalignments in date and time in your network nor significant network delays because this might impact JWT performance.
Self-Service Catalog: a business-oriented interface to submit on-demand business flow.
A new and improved version of the Self-Service Catalog is available. You can now launch your services quickly and easily and check on them at anytime by accessing the Self-Service Catalog from any device.
To use the Self-Service Catalog you do not need to be a Workload Automation expert, but you can leverage on services based on automation capabilities in no time, provided you are connected to the Dynamic Workload Console in Single Sign-On (SSO). For more information, see Configuring the Dynamic Workload Console for Single Sign-On topic in the Documentation.
The Workload Automation scheduler or application can now define services directly from the Workload Designer marking the job streams as services and specifying service parameters. As part of the job stream definition, the service definitions now can be easily transferred to a different environment
When creating and editing SSC-ready job streams, it is recommended you use the Dynamic Workload Console.
For more information about defining SSC-ready job streams, see the online help for job stream definitions in the Dynamic Workload Console and Job stream definition for editing the job stream from the command line in the Documentation.
The new command line interface to run jobs or job streams and to interact with Workload Automation server.
The installation package for Workload Automation contains the installation files for Orchestration CLI. After downloading the package, you can connect Orchestration CLI to any of the Workload Automation servers by configuring the config.yaml file. Orchestration CLI is a stand-alone application that can be used on any desktop or server, or on dynamic agents and replaces conman.
You can use the same Orchestration CLI with multiple servers of Workload Automation. Orchestration CLI is also compatible with later versions of Workload Automation and no need to update each time when the server is updated. For more information, see Orchestration CLI topic in the Documentation.