The outbound calls from ActiveControl to the external ticketing system can all be based on the Deployment Status of a change within ActiveControl.
Integration scenarios based on ActiveControl status changes are delivered as standard with the Integration Engine and therefore require no development.
The steps to set up this type of status based integration are:
1. Complete base Integration engine configuration. This includes identifying the endpoints of the integration and any mapping requirements. The mapping engine can be configured for most standard scenarios, but if complex mapping is required, ActiveControl user exits can be implemented to enhance the standard mapping routines. For more details on user exits and how they are implemented, please refer to a later section of this Administration Guide.
2. A trigger program should be scheduled to pick up the Task status changes that need to be interfaced to the external system(s). This trigger program selects the appropriate ActiveControl records, dependent on the configuration set up above, and passes it through the mapping engine. It then stores the mapped integration transactions into a set of standard tables.
Program Name: /BTI/TE_INTEG_TRIGGER
|External System The external system the trigger program will be run against|
|Task ID||Task(s) the trigger program will be run against|
|Task Type||Task Type(s) the trigger program will be run against|
|Task Reference||Task Reference the trigger program will be fun against|
|Task Priority||Task Priority the trigger program will be run against|
|Send previous changes||Select this checkbox if Task status changes is ‘backwards’ in the process and this change should be sent to the external system|
|Run as though Last Run on||The date and time of the ‘last’ run can be entered manually if this flag is checked|
|Run Date||The date of the last run (if manually entered)|
|Run Time||The time of the last run (if manually entered)|
3. A send program is then scheduled to pick up the mapped transactions and send them out to the configured external systems. It retrieves the required records and then uses the configured send methods for each particular integration scenario to actually push the data out to the receiving systems. If a standard send method is not available for a particular external system (maybe the ticketing system is a ‘home-grown’ application), then custom send methods can be created and utilised in the Integration Framework.
Program Name: /BTI/TE_INTEG_SEND
|External System||The system external system that the send program is to be run against|
|No. of Retries||The number of times the send program will try to send an integration transaction before issuing an error|
|Transaction Number||Specific integration transactions for the send program to process|
|Suppress Notifications||Makes sure that no notification emails are sent when the transactions are processed|
4. The outcome of the send process is recorded for audit purposes. If successful, any updates configured are made to the ActiveControl data objects, alternatively, if errors have occurred, the send program will try to re-send (if configured to do so) a certain number of times before marking the transaction in error and sending a notification to the relevant person(s) within the organisation.
5. At any time, the Integration Reporting Console can be used to see the status of all integrations, the status and history of each transaction and can also be used to update the underlying transactional data, if required, to fix errors.
Program Name: /BTI/TE_RINTEG_AUDIT
|Date||Date range for the report|
|Time||Time range for the report|
|All transactions/ Transactions in error||Select if all transactions should be displayed or just transactions in error|
|External System||Show only transactions for a specific external system|
|Transactions||Show only specific transaction numbers|
|Field Name||The external system field name|
|Field Value||The value in the external field|