Overview :

ServiceNow is a widely used service management tool in today's technical world. With its latest enhancements it has become a first choice of businesses looking for ITSM solution.  It is rapidly becoming a choice of storefront for lot of Hybrid cloud deployments.

 ServiceNow is now available in Software as a Service (SaaS) model to be consumed by on/off premise cloud solutions. This brings us to talk about a limitation with this model. Many customers have strict security policies which prevents an external (internet) application making calls to internal (intranet/private network) applications. Though there are possible networking solutions to circumvent this but some customers are still indifferent to those. 

The Solution

The solution to above mentioned problem needs to make sure that the service requests created on Servicenow reaches the cloud management platform  and cloud platform should be able to update the service request when it is done with its task. 

To achieve this we have developed a generic framework to integrate Service Now with vRA/VRO based on pull approach. The same approach can be leverage to integrate ServiceNow with other cloud management platforms as well. Details of the framework and approach is as follows:Details of the framework and approach is as follows:

System Architecture

• The above framework is in adherence to security requirement laid down by the customer(No external system can invoke a request on Client’s private network). Hence all interactions between vRA/VRO and Servicenow would be uni-directional and would be originating from vRA/vRO.
• vRO workflow will poll ServiceNow to pull all records from the required Queue and parse each request one by one and decide on type of request(day 1 or day2)
• vRO workflow will form the required payload and make a call to appropriate day 1 catalog item or day2 action
• vRA will invoke provisioning of VM on hypervisor if it’s a day 1 request or would invoke a day2 action on existing vm if it’s a day2 request.
• For every request parsed, a validation would be run to check the request content and in case there are any issues then vRO will set the acceptance flag of request on ServiceNow as OnHold else it will set is as Accepted.
• On completion of request , the vRO will update the corresponding record on ServiceNow as complete along with agreed relevant data.

Architecture Components

• ServiceNow : The  ServiceNow instance
• vRA: Component of Vmware vRealize Suite to host the catalog item for cloud management.
• vRO : Orchestration engine for the Vmware vRealize Suite cloud management tool
• Polling Workflow : vRO will be running a scheduled workflow to poll the ServiceNow queue at regular interval (5 min). With each poll request it will fetch all items from the queue . It will go over the returned items one by one and pass the payload to the Processing workflow. To prevent the slowing down of vRA/vRO only top 10 records will be processed and rest will be discarded until next run.
• Processing workflow : This workflow is the main workflow for the request processing. It will in-turn have multiple workflows/actions to perform the future activities.
• Parser: This workflow will parse the payload to identify the type of request (day1 or day2) and also catalog item/day2 action requested. It will create an appropriate properties object to be passed along with request. It will then invoke the appropriate validator workflow with properties object.
• Validator : There will be one validator workflow for each type of request. This workflow will validate the request for correctness of data. If data is as expected then it will call the error handling and status workflow to mark the request record as Accepted on Snow else it will mark it as ONHOLD using an API call to ServiceNow.
• Dispatcher Workflow: If request is accepted then the Validator Workflow will invoke the Dispatcher workflow with properties object which in-turn calls the VRA catalog item or day2 action. Dispatcher workflow keeps track of the request progress. If request is successful then it will call the Response update workflow with the required VM data (for day 1 request) or success/failure report in case of day2 actions. It will be an asynschronous workflow.
• Response update workflow: This workflow will update the corresponding Servicenow request record with the the agreed VM details or Request success/failure report.
• Error Handling workflow : This workflow is to handle the errors and exceptions occurred during the request lifetime.
• Provisioning workflow : Existing workflow to install agents and perform required configuration on the provisioned VMs.

Logical Flow:

Conclusion:

Using the above mentioned framework we were able to pull the records from ServiceNow and run the requests on cloud platform and update the request back on ServiceNow as per customer's security standards. 

Authors : Prashant Pareek  and Ashwara Sharma