The standard out of the box integration framework integrates at task level with third party software using task status changes as integration points. A process code will need to be attached to a task deployment or planning status which subsequently needs to be attached to a control point within ActiveControl. Assuming deployment/planning statuses have already been attached to control points within the path, we need to:
To link the process code with a deployment/planning status table ‘/BTI/TE_INT_PROC’ needs to be maintained here the status and process code is attached to the external system that is being integrated with.
| /BTI/TE_INT_PROC – Process Identifiers (per system) | |
|---|---|
| Field | Description |
| EXTSYS_NO | Main external system identifier, this is the identifier of the system that you wish to integrate with we can have as many systems as we want. An example of this could be: 1 – Remedy 1 – Solution Manager 2 – ServiceNow 3 – HP-ALM 4 - GitLab |
| EXTSYS_NAME | Full description of external system |
| IDENTIFIER | This identifier is the crux of the integration framework and denotes a point of integration, more than likely this would be some kind of internal id, in our OOTB example it is a task status. This point of integration is attached to a process code denoted above and this is what would cause an integration to be performed when this identifier is reached. |
| PROCESS_CODE | The process codes used by the integration framework to perform some kind of action. The framework gets shipped with two standard process codes CREATE and UPDATE. |
| IGNORE_CHANGES | This flag is set when you wish to ignore previous changes in case the integrated object has skipped through more than one integration point since the integration trigger program was last run. |
Process Identifiers (per system) = AC deployment status codes – codes found in SE16 table /BTI/TE_TASKSTAT
Post your comment on this topic.