ROAD MAP OF IBM ASPERA ORCHESTRATOR
MySQL from 5.1 to 5.7.
Added indexing to improve performance during frequent queries from high-volume users.
High-performance polling for new steps in a work order is now enabled by default.
When changing the password of another user, the value of the Current User’s Password field is now the password of the admin user who is making the change.
After installation, the system user is no longer enabled by default. An admin must activate the system user manual.
There is improved logging for SAML issues.
Updates to the Orchestrator UI
Logo, naming, color schemes, and other UI elements have been updated throughout the application to improve usability and conform with IBM Carbon standards.
The work order and work step details remain collapsed or expanded.
The left navigation menu remains collapsed or expanded while the UI is open.
A new user permission, Aspera:Orchestrator:JournalEntries: Edit allows admins to control which users and groups have access to the Delete button for journal entries. For more information on how to add permissions, see “Viewing and Granting Permissions” in the Admin Guide.
There are two new properties in the Orchestrator configuration:
1.recent_workflow_count – returns the specified number of workflows. The default value is 10.
2.minimal_xml_escaping – specifies how characters in XML responses for the Orchestrator endpoints are escaped. If false, all characters that are conventionally escaped in XML—according to best practices—are escaped. If true, only “<‘” and “&” are escaped.
The WorkStep Activity portlet now allows the user to specify which attribute to use for entry orders. By default, the ordering is done using the updated_at field.
The license page now displays the license information entered by an admin user. (CIM-3024)
Maintenance processes are now able to get updated values from the Orchestrator configuration file (/opt/aspera/var/config/orchestrator/orchestrator.yml) without the user having to run the actual orchestrator: restart.
Exporting workflows with multi-level dependencies is now levels of magnitude faster -from potentially over an hour to a few seconds.
In Orchestrator 3.2.0, we reintroduce the ability to access menu items for mapping the inputs and outputs of a step by right-clicking a step in the workflow.
Log statements from plugins now contain the plugin version number in addition to the Orchestrator version number (CIM-1600)
SAML and Orchestrator:
IBM Aspera Orchestrator 3.0.4 supports Security Assertion Markup Language (SAML) 2.0, an XML-based standard that allows secure web domains to exchange user authentication and authorization data. With the SAML model, you can configure Orchestrator as a SAML online service provider (SP) that contacts a separate online identity provider (IdP) to authenticate users. Authenticated users can then use Orchestrator to access secure content.
With SAML enabled, Orchestrator redirects a user to the IdP sign-on URL. The user signs in with the IdP and the IdP sends a SAML assertion back to Orchestrator, which grants the user access to Orchestrator. When a SAML user logs in to Orchestrator for the first time, Orchestrator automatically creates a new user account based on the information provided by the SAML response. Any changes subsequently made to the account on the DS server are not automatically picked up by Orchestrator.
You can now review the history of resources usage, which can help you optimize your workflows.
You now have the option to add a comment when editing a parameter in a workflow.
The workflow designer now displays which users are viewing and editing a workflow at any given time; also, users get an alert when the workflow is saved (updated) or published.
One or more workflows or and their dependencies can now be grouped together as a revision. Users can compare two such revisions to identify what has changed over time; for example, a remote node has been updated or a workflow has new steps.
You can now visualize a workflow as a dependency tree, including step dependencies, sub-workflows, and remote nodes.
Development and production machines can now directly deploy a workflow from one Orchestrator instance to another, either in the UI or with the new APIs. Note: Both Orchestrator instances must be v. 3.1.0 or newer.
Notes and parameters have been added to the documentation feature for each workflow, which already includes other elements added in the workflow designer, such as picture, steps, and mappings. The workflow documentation can be printed as a PDF.
A new workflow testing utility allows the user to simulate inputs and see workflow progress; you can include pre-processing and post-processing steps.
In the workflow designer, you can now make step outputs into global variables to be used in the workflow.
Journals and Journal Books:
In Orchestrator, journals are logs that collect run-time data about where a file can be found in the workflow. A journal book clusters all journal entries into categories. For example, if an Orchestrator system is handling files from two different media companies, the user can create two different journal books, called (for example) Company ABC and Company XYZ, to track the log entries. A journal book might also capture all the ingest steps across multiple workflows, for example.
Note: During an upgrade of Orchestrator, the system automatically creates a journal book called Misc Migrated Journals; all journals created in the previous version of Orchestrator are migrated into this journal book.
A remote node manages information needed to connect from a FASP Session, ASCMD, SSH, or TCP to a remote server. All plugins provide a dropdown arrow option to select a remote node for their plugin operations.
Without a remote node, you must input an IP address or host names, user ID, and password at multiple places in your workflows. If this information changes, your must change the information in multiple places. If you use a remote node and populate the information there instead, the only place the information changes in that node.