​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.

IBM Workload Scheduler satisfies Requests for Enhancements (RFEs). Requests for Enhancements (RFEs) give customers the opportunity to collaborate directly with the product development team and other users. The team prioritizes and develops new product features based on proposals made by customers. IBM Workload Scheduler V9.5 Fix Pack 2 delivers the following RFEs:

• RFE 138951: Support for an existing Oracle user.
  
• RFE 132029: Add run number check within MakePlan before locking the database.
• RFE: Allow configuration of the value for the global option untilDays.

Folder support has been extended to all scheduling objects. Gain greater business agility by organizing your scheduling objects in a hierarchy of folders. Organize them by lines of business, departments, geographies, or any custom category that makes sense for your business operations.
Move your objects into sub-folders, in batch mode, where the folder names are based on tokens contained in the names of the scheduling objects using the composer rename command.
Filtering for and monitoring your scheduling objects defined in folders means you no longer have to rely on complicated and restrictive naming conventions.
Furthermore, you can associate access control lists to individual folders to manage the security of your scheduling objects.

You can now encrypt your passwords using the {xor} or {aes} encoding before launching the installation scripts. To encrypt the passwords, you run a simple script, then provide the encrypted output to the installation commands (configureDb, serverinst, and dwcinst) or save it to the properties files for each command and run the installation process using the properties files.
The encryption mechanism is based on WebSphere Application Server Liberty Base, therefore you have to install WebSphere Application Server Liberty Base before you start installing the product, if you plan to use encrypted passwords.

Workload Automation, Lutist Development Kit is the new tool that enables you to create and publish your own integrations.

Ensure continuous operations with automatic failover and high availability capabilities. The automatic failover feature invokes an automatic switch from the master domain manager, event manager, or both, to a backup. Eligible backups for both the master domain manager and the event manager can be specified in separate lists, adding preferred backups at the top of the list. The backup engines monitor specific behaviors on the master domain manager to detect anomalous behavior (WebSphere Application Server Liberty Base is down, processes on the FTA of the master are down, or connection to database is lost due to a network outage). When the active master becomes unavailable, a long-term switchmgr operation is triggered.
In a high availability configuration, where the master and backup masters are configured behind a load balancer, workload requests are distributed across contactable backups, in addition to the master.