Overview
The Orchestration Service is a process that runs independently of the Terminology Server (although physically on the same box) and has the ability to drive a number of processes by making calls and routing files to server components such as:
- The Terminology Server
- Various JIRA instances
- The SRS (Snomed Release Service)
- The QVF - (Quality Validation Framework, previously RVF)
--[ Documentation to do: We should show how the Workbench Export is processed into a Backlog, Completed and BlackList from which components are selected to be imported into the Terminology Server]
Scheduled Jobs
The Orchestration Service has an internally scheduler (rather than relying on Jenkins to initiate activity, as we sometimes do) which kick off an import of content from the workbench at 05:00 UTC, and an export from the Terminology Server at 15:00 UTC. The Jobs and the related JIRA projects that track them through their associated lifecycles are shown in the following tables (one for each environment. It's probably worth logging in to JIRA and looking at the workflows for these projects to gain an understanding of the steps that the orchestration service is making.
User Intervention
User intervention may be required at two stages of the workflow:
- If queries are raised by the Terminology Server during classification
- If errors are spotted in the (SRS built) archive in the QVF
In each case, detailed information will be visible as comments against the relevant JIRA tickets. A user will be expected to either accept the data in it's current state, moving the ticket on to the next stage in the workflow, or reject the content. In the case of the daily workbench delta import, rejecting the data will result in the imported data being returned to the "Backlog" where it will be available for processing the next time the process is run.
Note that if a user does not intervene when intervention is required, then no further processing can take place for that particular JIRA project as we cannot load further data until the state of the previous data is decided ie merged to MAIN or returned where it came from.
Environment Wiring
Production JIRA Instance prod-workflow.ihtsdotools.org
Dev and UAT JIRA Instance uat-jira.ihtsdotools.org
Prod JIRA Project | UAT JIRA Project | Dev JIRA Project | Execution Time | WorkFlow | Purpose |
|---|---|---|---|---|---|
| TIP | TID | TIDD | 05:00 UTC | TIP Workflow | Tickets in the TIP track as authored components are selected from data exported from the Workbench and loaded onto a "Branch" in the Terminology Server which has the same name as the JIRA ticket. The data is classified, exported and passed to the SRS and RVF in turn. If a user accepts the defects listed in the RVF (and there are always defects), then the contents of the new JIRA named branch are merged into the MAIN branch. |
| TEP | TSE | TSED | 13:00 UTC | TEP Workflow | Tickets in this project track as unpublished content on the MAIN branch is classified, exported and passed to the SRS and RVF in turn. |