This document provides a concise overview of frequently asked questions. For a more comprehensive understanding of our products or services, please refer to our detailed online documentation on corresponding topic. Our online resources provide in-depth explanations and guidance.
Q. What is ITSM Integration?
ITSM integration involves connecting your ITSM platform with other applications through APIs (Application Programming Interfaces). This allows for seamless data synchronisation and event handling across different systems.
Q. What are the benefits of integrating ITSM systems?
Integrating ITSM with other tools can streamline workflows, reduce manual data entry, and improve overall efficiency. It helps in providing a unified view of IT operations, which can enhance decision-making and service delivery
Q. Which modules can be integrated with HCL BigFix SM?
All the modules that are required for HCL delivery to support the customer are available in HCL BigFix SM, which includes Incident, Service Request, Change, Problem & CMDB
Q. Which modules are covered in the BigFix SM Standard integration model?
Incident Management, Service Request management, Change Management (Bi-directional) & Problem Management (Uni-directional)
Q. How multiple catalogues in the customer ITSM system are integrated in HCL BigFix SM?
In accordance with HCL BigFix SM integration standards, a single catalogue per module is typically integrated to streamline the process. This contrasts with a one-to-one integration approach.
HCL BigFix SM employs a many-to-one integration strategy, where multiple catalogues from the customer’s ITSM system can be consolidated into a single catalogue within HCL BigFix SM, particularly for Incident Management and Service Request Management modules. When discrepancies arise in catalogue fields between the two systems, data is often concatenated to maintain consistency.
Q. What is BigFix SM Integration Engine & where it is hosted?
A middleware component tightly coupled with HCL BigFix SM. BigFix SM-IE is designed to adhere to industry standards on authentication, authorization, and data encryption. BigFix SM- IE which acts as integration layer, is responsible for:
- Exposing RESTful APIs for external systems to interact with HCL BigFix SM
- Transforming data between HCL BigFix SM and external systems, ensuring compatibility and adherence to data standards
- Handling authentication, authorization, and security protocols
- Managing data mapping and synchronisation rules
Q. Do we need to onboard the customer’s entire user base on HCL BigFix SM?
One of the many benefits of ITSM tool integration is that the entire user base does not need to be onboarded to the new ITSM tool. This helps avoid cultural change for the customer user base.
Q. What is the difference between Unidirectional & Bi-directional ITSM Integration?
- Bi-directional ITSM Integration refers to the seamless and automated exchange of data between two or more ITSM systems in both directions. This means that changes (Create & update) made in one system are automatically reflected in the other, and vice versa.
- Uni-directional ITSM Integration refers to a data flow between two ITSM systems in one direction only. Ticket creation is done from one system to another, but not vice versa, however the updates will flow in both directions.
Q. What common scenarios are typically covered in case of Bi-directional ITSM integration?
- HCL BigFix SM is both ticket initiator and resolver system
- HCL BigFix SM is ticket initiator system and customer ITSM is resolver system
- Customer ITSM is ticket initiator system and HCL BigFix SM is resolver system
Q. What common scenarios are typically covered in case of Unidirectional ITSM integration?
- HCL BigFix SM is both ticket initiator and investigator system
- Client ITSM is ticket initiator system and HCL BigFix SM is investigator system
Q. How are status, priority, and group assignments handled during the integration process?
Status, priority, and group assignment scenarios along with other use cases are thoroughly discussed and documented during the field mapping discussion phase. This included mutual agreement on field mappings and dedicated project time for comprehensive review.
Q. Does HCL BigFix SM expose its API directly to the customer ITSM system?
In order to achieve integration between shared instances of HCL BigFix SM and multiple ITSM / Non-ITSM systems, the API of the BigFix SM Integration Engine, which acts as a middleware layer, is shared with the client.
Q. How is the connectivity between the customer’s ITSM system and HCL BigFix SM established?
Both (Customer & HCL BigFix SM) ITSM tools should expose endpoints, APIs & exchange credentials over the Internet to establish connectivity for both inbound and outbound connections.
Q. Is custom development required in the customer’s ITSM tool to integrate it with HCL BigFix SM?
Post integration discussion, parallel development will occur on both the client’s ITSM system and HCL BigFix SM to configure systems for data exchange as per the agreement. The documented field mapping sheet, agreed scenarios, BigFix SM-IE API & onboarding and eBonding overview documents will serve as the entry gate, and the developed integration between the two systems is the output. Client ITSM system to be able to send data to HCL BigFix SM via the standard set of payloads (JSON format) which HCL BigFix SM accepts. The exact payloads will be shared during the integration discussions.
Q. What all development is required on the customer ITSM to enable this integration?
To enable this integration, development efforts will be required on the customer’s ITSM system. While it’s challenging to provide a definitive list of activities and the associated effort, our experience suggests the following tasks may be involved
- API Development: Creating endpoints, handling payloads, and implementing authentication mechanisms.
- Data Mapping and Transformation: Ensuring compatibility between the customer’s ITSM system and HCL BigFix SM data structures.
- Error Handling and Logging: Implementing robust mechanisms to manage exceptions and track integration performance.
- Testing and Validation: Thoroughly testing the integration to ensure it meets functional and non-functional requirements.
- Deployment: Migrating code from non-production to production environments.
Q. What are the prerequisites for a customer to establish this integration?
Below are the key prerequisites for ITSM Integration. For a detailed and comprehensive list, please refer to the module onboarding & eBonding overview document.
- The client’s ITSM system must support RESTful API-based integration using POST method
- Availability of APIs (accept and transfer ticket data) and credentials at client’s ITSM system.
- BigFix SM-IE payloads (both inbound and outbound) are not customizable. Hence it is important that the client’s ITSM system will need to be able to exchange data with HCL BigFix SM using a standard JSON payload format. This is a standard format that HCL BigFix SM accepts and expects client systems to understand. The information regarding the standard JSON payloads is available in the BigFix SM-IE API reference document & will be discussed in detail during the integration discussions
- ITSM tool to be able to expose APIs over Internet to establish connectivity between two systems
- Client ITSM system to support one of the authentication mechanisms (Basic, API Key or JSON Web Token- JWT Authentication.
- The client’s ITSM system should incorporate an error handling mechanism to manage data exchange errors between the two systems, ensuring seamless inbound and outbound connections.
Q. How and when will the integration scenarios or use cases be finalised?
A dedicated time slot has been allocated within the project plan for detailed discussions between customer ITSM SPOCs and the HCL BigFix SM Functional Consultant. During these sessions, standard integration scenarios, use cases, and field mappings will be defined, agreed upon, and finalised prior to implementation.
Q. How will the payload and APIs be configured for this integration?
A comprehensive HCL BigFix SM API document, outlining standard payloads and APIs is available and published. Following finalisation of scenarios and field mappings, both the customer’s and HCL BigFix SM’s technical teams will configure their respective systems to establish the integration based on the provided specifications.
Q. How will error handling be implemented for this integration?
A standardised error handling mechanism is defined within the HCL BigFix SM error handling document and will be implemented accordingly. HCL BigFix SM will attempt API calls up to three times before failing. Standard HTTP error codes will be used to notify the client ITSM system of any issues. It is recommended that the client ITSM system should implement comparable error handling and retry logic to maintain data integrity and reliability during data exchange.
Q. What are the responsibilities of the customer’s ITSM Technical Consultant during this integration project?
The Client ITSM Technical Consultant will play a pivotal role in the integration process. Their responsibilities include active participation in integration discussions, development and implementation of the integration within the client’s ITSM tool based on the agreed-upon standard approach, contributing to functional and user acceptance testing, and ultimately deploying the code to the production environment.
Q. What is HCL’s standard approach to ITSM integration & what modifications would be considered customizations within the standard integration approach?
The integration approach, APIs, and error handling mechanisms outlined in the HCL BigFix SM ITSM integration documentation constitute as standard. Any deviations from this standard, such as custom payloads or modified integration approach or methodology, will be considered customizations.
Q. What common RESTful API method is typically used for this integration?
HCL BigFix SM primarily utilises RESTful API-based integration with the POST method as part of its standard integration approach
Q. Is the acknowledgement/response for this integration synchronous or asynchronous?
Upon successful authentication, an ITSM tool’s request to the HCL BigFix SM-IE API will get either a synchronous or asynchronous response from BigFix SM-IE, depending on the situation. All standard HTTP error responses (2xx,4xx or 5xx) from BigFix SM-IE are generally synchronous.
Q. What API authentication method is used during the integration?
HCL BigFix SM primarily supports 3 types of API Authentication for establishing connectivity.
- Basic Authentication: User ID and Password, recommendation with user ID is that in the external system this must not be allowed to logon interactively. The password shared are encrypted using TLS 2.0
- API Key authentication: Using API keys is a way to authenticate an application accessing the API, without referencing an actual user. The app (client)adds the key to each API request, and the API can use the key to identify the application and authorise the request. How the key is sent differs between APIs. Some APIs use query parameters, some use the Authorise header, some use the body parameters. An API key is a token that a client provides when making API calls. The key can be sent in the query string or in the header. For authentication, the client sends HTTPS requests with the API Key header that contains its value.
- JSON Web Token (JWT) authentication: Is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. BigFix SM Integration Engine supports JWT signed using a secret (with the HMAC algorithm with SHA-256) or a public/private key pair using RSA 256 (RSA Signature with SHA-256)
Q. What type of data encryption is supported for data at rest and in transit?
HCL BigFix SM is hosted on AWS Cloud, providing robust data security through encryption both in transit and at rest.
Data in transit: Encrypted using TLS for Amazon EFS and benefiting from AWS’s inherent network encryption.
Data at rest: Protected by encryption features offered by AWS services like Amazon EBS and Amazon S3, with the option of using AWS CloudHSM for heightened security and compliance.
These measures collectively safeguard customer data within the HCL BigFix SM environment.
Q. How is communication about new release consumption handled between customers and the HCL delivery team?
BigFix SM HCL typically adopts new releases quarterly. Prior to production deployment, each release undergoes rigorous testing in a non-production environment. Once all identified bugs are resolved, the release is pushed to production. HCL Delivery teams receive advance change notification of these deployments through MTaaS updates, they will further inform the customer.
Q. What non-ITSM integration is possible with HCL BigFix SM?
HCL BigFix SM is capable with any system which offers integration via RESTful APIs. In addition to ITSM module integration and predefined standard approach for HCL internal tools like Moogssoft, iAutomate, and MyCloud is available, integration with other non-ITSM tools such as HCL BigFix, SCCM, Intune, and multiple Discovery applications can be achieved through RESTful API based integration.
Q. What is the hyper care period?
HCL ISM provides dedicated hypercare support for a period of one week (five business days) following the successful production migration of newly onboarded customers and integrations. During this hypercare window, the HCL ISM team prioritises tickets, including incidents and service requests.
Q. How the incident & Service request would be managed in Operations?
The HCL Delivery team can create tickets using the available catalogues on the Service Catalogues page. They can submit incidents or service requests as needed.