Introduction
Integration is used to enable the electronic exchange of tickets between a Customer ITSM and HCL BigFix SM. Tickets are updated and synched between both the systems throughout the lifecycle of the ticket through the implementation of integration transactions.
HCL standard integration approach is a set of states, actions (transactions) and data elements that are shared between customer ITSM and HCL BigFix SM shared instance to enable information exchange. Standard integration does not include integrating the event generated tickets between two ITSM system.
Purpose
This document elaborates the standardized solution for integration of transactional incident tickets between the customer IT service management (ITSM) application and the shared instance of HCL BigFix SM platform. This feature is also sometimes known as Integration or ebonding of the tickets. Depending on the scope of work, integration can be Uni-directional (Ticket creation from one ITSM tool) or Bi-directional (Ticket creation from both the ITSM tools).
This document must be used together with the Field Mapping Sheet (FMS) to ensure attributes/fields referenced in this document are adequately mapped in the FMS. Any mention of HCL BigFix SM instance in this document refers to the shared instance of HCL BigFix SM.
Intended Audience
The intended audience for this document is Customer and HCL stakeholders involved in the ebonding, as per the scope and project plan.
Related Documents
This document relates with the following document.
- API Reference Guide for HCL BigFix SM Integration Engine
- Module Onboarding & Integration - Approach & Prerequisites
- HCL BigFix SM Integration Error Handling Approach
- Standard Field Mapping Sheet ( Shared during the kickoff discussions)
Tenets of the Solution
There are a few solution tenets which underpin the complete solution and will be referred repeatedly throughout the solution.
Process Ownership of the transaction ticket: In case of a transaction ticket, there are two likely scenarios in any integration.
⢠Ticket initiator is the external ITSM and HCL BigFix SM is the resolver.
⢠Ticket initiator is HCL BigFix SM and the external ITSM is the resolver.
In either of the case, the system which initiates the ticket will be the process owner. The other system will be the resolver.
Process to Task integration: Only one of the systems will be the process owner as explained in the first tenet. Therefore, the nature of the integration would be process to task. The target system would function purely as a resolver and send the information back to the initiator system.
Integration Block Diagram
Below is the high-level block diagram of the Incident Management Bi-directional integration.
Prerequisites
To successfully integration Incident Management module, below is the summary of prerequisites. For details around these prerequisites, reader is advised to refer to document Module Onboarding & Integration - Approach & Prerequisites
- System compatibility: The clientâs ITSM system must support RESTful APIs, specific data formats (JSON), and error handling.
- Network connectivity: A stable internet connection is necessary for communication between the two systems.
- Data requirements: Clear identification of ticket data, business rules, and mapping between the two systems is crucial.
- Technical requirements: API documentation, technical expertise, and a testing environment are essential for successful integration.
Scenarios for IM Integration
Case 1: Initiator and Resolver is HCL BigFix SM
Following are the scenarios for ticket exchange between HCL BigFix SM and Customer ITSM
| Scenario | Trigger Condition | Flow |
|---|---|---|
| 1. Incident ticket Creation | New Incident ticket submitted in HCL BigFix SM. | a. Incident ticket is created in HCL BigFix SM and INC integration is triggered to Customer ITSM for visibility only. b. INC is assigned to âHCL Support groupâ in HCL BigFix SM ITSM, with catalogues having externally fulfilled âYesâ. c. Incident Status in HCL BigFix SM = Submitted. d. Incident ticket is created successfully on Customer ITSM tool. |
| 2. Incident ticket Cancellation | INC ticket is cancelled in HCL BigFix SM | a. Requester & Support user both can requests for cancellation before the Incident is Resolved. b. Cancel trigger is sent to Customer ITSM tool through update API. c. Incident Status in HCL BigFix SM = Cancelled. d. Corresponding status on the integrated INC ticket will be updated on Customer ITSM tool. As a recommendation, these tickets should not be cancelled from customer ITSM tool. |
| 3. Incident ticket status WIP | The resolver team accepts the ownership of INC on HCL BigFix SM and changes the ticket status to âIn Progressâ | a. Resolver group accepts the resolution ownership of the INC and assigns it to an individual on HCL BigFix SM. b. Resolver changes the status of the incident ticket to âIn Progressâ. c. Incident status in HCL BigFix SM = In Progress. d. Corresponding status on the integrated INC ticket will be updated on Customer ITSM tool. |
| 4. Update by Support group | Update performed on an integrated Incident ticket on HCL BigFix SM. | a. While working on an integrated Incident ticket resolver on HCL BigFix SM may perform updates to the ticket. b. The corresponding modified fields (Work notes, Priority, Status & Attachment) on the integrated ticket will be updated on Customer ITSM tool. As a recommendation, customer should not be updating the status and priority for these tickets in their tool, however, he can update work notes and attachment, as and when required. |
| 5. Incident ticket status Pending | Resolver updates integrated INC status/Sub-status to âPendingâ on HCL BigFix SM. | a. Depending on the reason, resolver will put the INC ticket on âPendingâ status in HCL BigFix SM. b. Resolver will select the relevant âPendingâ reason on HCL BigFix SM. c. The corresponding status / sub-status on the ticket form will be updated on customer ITSM, as per the Field Mapping Sheet (FMS). |
| 6. Update by Requester | Update performed on an integrated INC on HCL BigFix SM i.e. (Status, Work notes & Attachment) are updated. | a. Requestor updates the (Status, Work notes & Attachment) on an integrated Incident ticket in HCL BigFix SM. b. Requestor can change status to Cancelled or Reopen, on HCL BigFix SM. c. Corresponding Status, Work notes & Attachment on the integrated INC ticket will be successfully updated on customer ITSM tool. |
| 7. Incident ticket Resolution | Integrated INC ticket is resolved on HCL BigFix SM. | a. Integrated INC ticket is resolved by the resolver on HCL BigFix SM. c. Incident Status on HCL BigFix SM = Fixed, Sub status = âPermanently resolvedâ. c. The status on the ticket form and fields will be successfully updated on Customer ITSM tool. Resolver can select of one of applicable Sub Status (Type of Fix) available in BigFix SM. |
| 8. Incident ticket Closed | Requester accepts resolution on HCL BigFix SM. | a. Once the resolution is accepted, the Incident status will be Closed on HCL BigFix SM. b. Incident Status on HCL BigFix SM = Closed. c. Corresponding status will be successfully updated on Customer ITSM tool. |
| 9. Incident ticket auto-Closed | Integrated INC ticket is marked as Fixed. | a. As per 7 calendar days policy, the ticket will be auto closed in HCL BigFix SM. b. Incident Status on HCL BigFix SM = Closed. c. Corresponding status on the integrated INC ticket will be updated on Customer ITSM tool. |
| 10. Incident ticket Reopen | Requester re-opens the Incident ticket on HCL BigFix SM. | a. While re-opening the ticket on HCL BigFix SM, End user will update the reason for reopening the Incident ticket in comments. b. Incident Status on HCL BigFix SM = Submitted. c. Last assignment group name will be populated in INC ticket on HCL BigFix SM. d. Corresponding status on the ticket will be updated on Customer ITSM tool. Kindly refer to the auto-closure policy in the consideration |
Case 2. Initiator Customer ITSM tool and Resolver HCL BigFix SM
In this scenario for ticket exchange between Customer ITSM (Initiator) and HCL BigFix SM (Resolver). the tickets which require resolution by a support team will be e-bonded with HCL BigFix SM.
| Scenario | Trigger Condition | Flow |
|---|---|---|
| 1. Incident ticket Creation | New Incident ticket submitted in Customer ITSM tool & assigned to integration assignment group < Group name> | a. Incident ticket is created in Customer ITSM tool & INC is assigned to âHCL Support groupâ b. INC integration is triggered, and INC is created in HCL BigFix SM. c. Incident Status in HCL BigFix SM = Submitted. |
| 2. Incident ticket Cancellation | INC ticket cancelled in Customer ITSM tool | a. Requestor cancelled the INC on customer ITSM tool. b. Cancellation status is sent to HCL BigFix SM. c. Corresponding status is updated on HCL BigFix SM. |
| 3. Incident ticket status WIP | The Resolver accepts the ownership of INC on HCL BigFix SM and changes the ticket status to âIn Progressâ | a. Resolver group accepts the resolution ownership of the INC and assigns it to an individual. b. Resolver changes the status of the incident ticket to âIn Progressâ on HCL BigFix SM. c. The status on the INC ticket will be successfully updated on Customer ITSM tool. |
| 4. Update by Resolver | Resolver updates (Work notes, Priority, Attachment & Status) on integrated incident on HCL BigFix SM. | a. Resolver modifies Work notes, Priority, Attachment or Status on the INC ticket on HCL BigFix SM. b. Corresponding INC ticket will be successfully updated on Customer ITSM tool. |
| 5. Incident ticket status Pending | Resolver updates status of integrated INC to âPendingâ and selects applicable Sub-status on HCL BigFix SM. | a. Depending on the reason, resolver will put the INC ticket on âPendingâ status in HCL BigFix SM. b. Resolver will select the relevant âPendingâ reason on HCL BigFix SM. c. The corresponding status / sub-status on the ticket form will be updated on customer ITSM, as per the Field Mapping Sheet (FMS). |
| 6. Update by Requester | Requester updates integrated INC on customer ITSM tool i.e. (Status, Work notes, Priority & Attachment). | a. Requestor updates the (Status, Work notes, Priority & Attachment) on an integrated Incident ticket in customer ITSM tool. b. Corresponding Status, Work notes, Priority & Attachment will be updated on integrated INC ticket on HCL BigFix SM. |
| 7. Incident ticket Resolution | Resolver changes the status of the integrated incident to âFixedâ on HCL BigFix SM. | a. Integrated ticket is marked as âFixedâ by Resolver on HCL BigFix SM. b. INC âCauseâ, âType of Fixâ and âFix Providedâ is mandatory to be updated by the Support group user at the time of Resolution. c. Corresponding status on the INC ticket form and fields will be successfully updated on Customer ITSM tool, as agreed in the field mapping sheet (FMS). Resolver can select of one of applicable Sub Status (Type of Fix) available in BigFix SM. |
| 8. Incident ticket Closed | Initiator accepts resolution on Customer ITSM tool. | a. Once the resolution is accepted on Customer ITSM tool, the Incident status will be Closed. b. The status on the integrated INC ticket will be successfully updated to Closed on HCL BigFix SM. |
| 9. Incident ticket auto-Closed | Incident status set to Resolved on Customer ITSM tool. | a. No action is taken by initiator after the resolution on Customer ITSM tool. b. As per 7 calendar days policy, the ticket will be auto closed in HCL BigFix SM. c. Corresponding status on the ticket form will be successfully updated on Customer ITSM tool. Kindly refer to the auto-closure policy in the consideration |
| 10. Incident ticket Reopen | Initiator rejects resolution or Incident ticket is re-opened on Customer ITSM tool. | a. Once the Incident ticket is rejected or reopened on Customer ITSM tool, Initiator will update the reason for reopening the Incident ticket in comments. b. Incident Status in HCL BigFix SM = Submitted c. Last assignment group will be populated in INC ticket d. Corresponding status on the integrated INC ticket will be updated on HCL BigFix SM. Kindly refer to the auto-closure policy in the consideration |
Case 3. Initiator HCL BigFix SM and Resolver Customer ITSM tool
| Scenario | Trigger Condition | Flow |
|---|---|---|
| 1. Incident Ticket Creation | New Incident ticket submitted in HCL BigFix SM. | a. Incident ticket is created in HCL BigFix SM and INC integration is triggered to Customer ITSM b. INC is assigned to âHCL Support groupâ in HCL BigFix SM ITSM, with catalogs having externally fulfilled âYesâ and Unique catalog name and service ID. c. Incident Status = Assigned d. The status on the ticket form will be successfully updated on Customer ITSM tool. |
| 2. Incident Ticket Cancellation | INC ticket is cancelled on either of the ITSM tools. | a. Either of Initiator & Resolver can request for cancellation before the Incident is Resolved. b. Cancel trigger is sent to Resolver ITSM tool through update API. c. Incident Status in HCL BigFix SM = Cancelled d. The status on the INC ticket will be successfully updated on Customer ITSM tool. |
| 3. Incident Ticket Status WIP | The Resolver group accepts the ownership of INC on Customer ITSM tool and changes the ticket status to âWork in Progressâ. | a. Resolver accepts the resolution ownership of the INC and assigns it to an individual. b. Resolver changes the status of the incident ticket to âWork in Progressâ. c. Incident status in HCL BigFix SM = In Progress d. The status on the ticket form will be successfully updated on both ITSM tools. |
| 4. Update by Resolver | Update performed on an integrated Incident ticket on Customer ITSM tool. | a. While working on an integrated Incident ticket resolver on Customer ITSM tool may perform updates to the ticket. b. The corresponding fields (Status, Work notes, Priority, Status & Attachment) on the INC ticket will be updated on HCL BigFix SM. |
| 5. Incident Ticket Status Pending | Resolver updates integrated INC status/Sub-status on Customer ITSM tool. | a. Depending on the reason, resolver will put the INC ticket on âPendingâ status in the customer ITSM tool. b. Resolver will select the relevant âPendingâ reason on customer ITSM tool. c. The corresponding status / sub-status on the ticket form will be updated on HCL BigFix SM, as per the Field Mapping Sheet (FMS). |
| 6. Update by Requester | Requester updates integrated INC on HCL BigFix SM i.e. (Status, Work notes, Priority & Attachment). | a. Requestor updates the (Status, Work notes, Priority & Attachment) on an integrated Incident ticket in HCL BigFix SM. b. Corresponding Status, Work notes, Priority & Attachment will be successfully updated on customer ITSM tool. |
| 7. Incident Ticket Resolution | The Support group member resolves an integrated INC ticket in Customer ITSM tool. | a. Integrated INC ticket is resolved by the Support group user on Customer ITSM tool. b. Incident Status on HCL BigFix SM = Resolved, Sub status = âPermanently resolvedâ. c. The status on the ticket form and fields will be successfully updated on HCL BigFix SM. Resolver can select of one of applicable Sub Status (Type of Fix) available in BigFix SM. |
| 8. Incident Ticket Closed | The requester accepts the resolution of an integrated INC ticket on HCL BigFix SM. | a. Once the resolution is accepted on HCL BigFix SM, the Incident status will be Closed on HCL BigFix SM. b. Incident Status on HCL BigFix SM = Closed c. The status on the ticket form will be successfully updated on Customer ITSM tool. |
| 9. Incident Ticket Auto-Closed | Integrated INC ticket is marked as Fixed. | a. As per 7 calendar days policy, the ticket will be auto closed in HCL BigFix SM. b. Incident Status on HCL BigFix SM = Closed c. The status on the INC ticket will be updated on Customer ITSM tool. Kindly refer to the auto-closure policy in the consideration |
| 10. Incident Ticket Reopen | Requester re-opens the Incident ticket on HCL BigFix SM. | a. Once the Incident ticket is rejected or reopened on HCL BigFix SM, Initiator will update the reason for reopening the Incident ticket in comments. b. Incident Status in HCL BigFix SM = Submitted c. Last assignment group will be populated in INC ticket d. Corresponding status on the ticket form will be successfully updated on HCL BigFix SM. Kindly refer to the auto-closure policy in the consideration |
Integration Flow
Ticket created in customer ITSM system
Ticket created in HCL BigFix SM
Incident Management Integration Considerations
Below are the key considerations which should be considered while establishing the integration between two ITSM systems:
- Integration will be established using standard (non-customizable) payloads & APIs, shared by HCL BigFix SM FC/TC.
- Standard integration does not include integrating the event generated tickets between two ITSM system.
- HCL BigFix SM is shared instance with data segregation controls.
- Payloads must adhere to the format mentioned in API document.
- Attachments must be sent in Base64 encoding.
- API Authentication â HCL BigFix SM Integration Engine supports multiple Authentication Methods, mentioned in the API and Payloads document.
- Integration shall happen between Incident Management modules in both systems.
- Re-assignment and ticket ownership transfer will not happen between HCL BigFix SM & Customer ITSM.
- Email notification to users shall be sent from the respective ITSM tool to Initiator & Resolver. It will not be catered as a part of Integration.
- Field mapping sheet for incident integration will be prepared in collaboration with customer FC & TC.
- Ticket lifecycle will be followed in only one system who will be process owner as per solution tenets.
- Maximum attachment size shall be 5 MB per attachment for both inbound & outbound in HCL BigFix SM.
- Field length and field type at both the ITSM tools should match. If the field lengths do not match, then the excess characters will be truncated.
- SLAs will be applicable on the incidents accordingly from the time Incidents were created in HCL BigFix SM. SLAâs will not be integrated and will run independently on both tools.
- The status transitions in initiator ITSM tool will be governed by the status transitions occurring at resolver ITSM tool. When ticket is auto closed in HCL BigFix SM (as per 7 calendar days policy), there are two scenarios:
- Manual closure or auto-closure policy in Customer ITSM is less than 7 days. This is acceptable scenario
- Manual closure or auto-closure policy in Customer ITSM is more than 7 days. In this scenario HCL BigFix SM policy will override Customer ITSM policy or else Customer needs to amend policy at their end.
- Each ITSM tool will follow its time zone configured in its system for maintaining the timestamps in the work-log. So at times, there may be two different timestamps based on the time-zone difference in both the tools.
- Both the ITSM tools will use GMT / Epoch format to communicate time stamps through integration.
- If mandatory data fields are not passed, ticket exchange will not happen.
- Any change in list of values of mapped fields at either end will affect data exchange.
- Process must be defined explicitly on handling incorrectly assigned tickets or else it may lead to orphan tickets lying in the ITSM system at both ends. Additionally, ticket transfer process must be defined when tickets pass from one tool to another to avoid any orphan tickets in the system.