Offer deployment based on dependencies and changes of objects

Current Situation

JOC Cockpit supports deploying/releasing one or more single objects and objects from folders of the inventory. Dependency checks of referenced objects are not performed the API and are partially performed by the GUI.

Desired Behavior

• Milestone 1: Dependency Management (technical dependencies)
  • A technical dependency is the relation between two objects in the inventory with one object referencing another object, for example a File Order Source referencing a Workflow
    • For the referencing object to work properly, the referenced object has to be present, valid and deployed/released.
  • When objects from the inventory are changed and are selected for deploying/releasing, then all referenced objects and all objects holding references to the changed object have to be checked and have to be deployed/released in a single operation.
  • Implementation
    • Data Model
      • A table INV_DEPENDENCIES is introduced that holds the INV_CONFIGURATIONS.ID of the referencing object as its primary key and the related ID of the referenced object in a separate column. In addition, a column for the "published" status is available. The table holds records for draft objects and for deployed/released objects.
    • API
      • The /inventory/store API will populate the INV_DEPENDENCIES table for the current object.
      • The API implements a rule set to put a referenced object in draft mode if the referencing object is changed:
        • The type of change is relevant:
          • Renaming an object will always trigger dependent objects to be put in draft mode.
          • For workflows that are added/modified workflow variables related schedules are put in draft mode. For the precise rule see JOC-1788.
          • to be extended.
      • The API is added /inventory/dependencies that is parameterized from an array of objects holding the object name and object type for which dependencies are requested. The result includes the deployables and releaseable objects including related properties that map to the structure required for use with calls to /inventory/deployment/deploy and /inventory/release.
    • GUI
      • When deploying/releasing an object then the GUI will perform the following steps:
        • Call the /inventory/dependencies API.
        • From the response use the deployables object to populate the call to /inventory/deployment/deploy. If the response's releasables object is empty update the Daily Plan in line to what the user selected (now, date, no).
        • Provided that the releaables object is not empty
          • from the response use the releasables object to populate the call to /inventory/release.
          • update the Daily Plan in line to what the user selected (now, date, no).
    • The same sequence of steps is performed if the user deploys a deployable object or releases a releasable object.
• Milestone 2: Change Management (business defined dependencies)
  • A business defined dependency is a relation between objects that is user defined, for example changes to two Workflows that are not technically related but that are caused by business rules.
  • Users can define a Change to consistently deploy/release or to remove objects:
    • A Change is applied to a number of objects in the inventory to which the user adds the relation.
      • For example, a number of workflows should be changed and should be deployed from a single operation to guarantee consistency. The objects are not necessarily related by technical dependencies.
  • Deployment, releasing and removal of objects should be improved to support the selection of Changes for consistent operations on a number of objects.
  • Implementation
    • Data Model
      • A table INV_CHANGES is added that holds metadata of the change including the change owner, title, description, start date, end date and status (open, published) of the change.
      • A table INV_CHANGE_RELATIONS is added that holds the INV_CHANGES.ID as its primary key and the related ID of the inventory item subject to change from a second column.
    • API
      • The APIs /inventory/changes/add, /inventory/changes/delete and /inventory/changes (list) are added to mange changes
      • The APIs /inventory/changes/items/add, /inventory/changes/items/delete and /inventory/changes/items (list) are added to manage inventory objects that are subject to the related change.
    • GUI
      • To JOC Cockpit's administrative menu (wheel) the following item is added: "Manage Changes". The menu item is added right after the "Manage Deployments" menu item.
        • Clicking the menu item opens a page with the list of changes (similar to the list of "Encryption Keys"). Users find a button "Add Change". Users find the operations "edit" and "delete" per list item action menu that map to the related API calls.
        • The GUI offers input fields for a change corresponding to the above data model.
      • In the Configuration->Inventory view
        • users find the action menu items "Add to Change" and "Remove from Change" that will call the /inventory/changes/items/add and /inventory/changes/items/delete API accordingly.
      • users find the action menu item "Publish Change" that will perform both operations to deploy and to release objects that have been added to the change. The change is identified from the object from which the action menu item is used. The GUI will perform the same steps as indicated with "Milestone 1". The implication is that all deployable objects make it for a single call to /inventory/deployment/deploy. Similarly all releasalbe objects make it for a single call to /inventory/release.
        • The "Publish Change" action menu item is available at any folder level in the tree: user folders, system folders (Controller/Automation) and object folders (Workflows, Schedules etc.). A popup window is displayed that offers the list of open changes. The user can select a change and perform the "Publish Change" operation accordingly. This action menu item is available only for SecurityLevels Low and Medium.
        • SecurityLevel High
          • When the user klicks  on the export button a modal window is opened
          • In the modal window the user will select the checkbox "for signing" to export a set of objects
          • a radio button is already available that provides a selection between using folders or individual objects. The radio button has to be updated to provide a third option "changes".
          • When the option is selected the modal window should show a list of changes the user can select from.
          • The export API, specifically the "for Signing" option, has to be extended to be able to process changes (request schema and api implementation)