This article will show you how we used the integration platform ONEiO to set up an ordering and delivery process of hardware items and tech services from an external provider, utilizing ServiceNow.
ONEiO is an integration platform that helps solving integration challenges in a more efficient, scalable and cost efficient way. OneiO can for instance be used to integrate ServiceNow with Jira, Salesforce, MS Teams or other ServiceNow instances.
In this particular case, the task at hand is to establish an ordering and delivery process of hardware items and tech services from an external provider. It requires a fast and stable connection between the endpoints, and we want to make it low-code, so it is quick to implement and easy to adjust.
General design of the solution assumes that the communication will run through ONEiO. It will receive data from the ServiceNow instance, process and redirect them further to the tech provider endpoint. The return communication will work in the same way.
ServiceNow needs to be prepared to connect with ONEiO. For this purpose, a Unifi application is utilized to establish bidirectional synchronous connection. To make it work, you need to set up a new process. In this case we have a Vendor Order Process, which represents the business process of ordering and delivering tech items. Next step is to add an integration record where some basic configuration has to be added, such as integration name, service type (REST/SOAP) or message type (JSON/XML/Advanced).
We continue by setting up a connection between serviceNow and ONEiO, where details such as environment type (Development / Sandbox / Test / Production), endpoint url and user are given.To make outbound messages work, we don’t need any specific rights or roles, but to make inbound connection work a user is needed to have appropriate access rights; 'itil' and 'x_snd_eb_integration'. To make the connection work, you need to have a user with appropriate access rights - 'itil' and 'x_snd_eb_integration'.
Next task is to configure ONEiO to be prepared to receive messages from ServiceNow. Routing rule helps to identify a message as an “Order” by checking Conditions. “Order” contains all basic information which should be included in the message (ordered products, receiver information, quantity etc). This message always initiates conversation, so it will always be sent first. In this case the “message_type” attribute needs to have a value set for “Order” to identify the message correctly.
ONEiO gives us the possibility to map content which is received from ServiceNow. In our case the provider who will get the message requires XML format. This is set in the “Mappings” tab. All data can be populated dynamically by all types of variables.
Conversation variables are mapped within the routing rules. All mapping features, including formatters, are available with runtime variables. Conversation is one process, starting from ordering the product and ending with delivery. As part of conversation, we may use the above-mentioned variables. In our case the most important is the “request_number” variable which is a key to connect the supplier system with the ServiceNow fulfillment process.
“OrderResponse” is a routing rule which waits for a response from a supplier. To determine if this message is actually a “response”, message rule checks if there is a correct XML attribute in there. Response contains some basic information about the order, for example if there is any error during receiving the order, or estimated delivery time for request. ServiceNow recognises this message as “On order” state. From this point, ServiceNow knows that the order is generated successfully in the vendor system.
After the supplier completes and sends the order, a message is sent to ONEiO. The Routing rule waits for a message containing proper attributes in received XML and recognizes it as “Delivery”. It’s similar process as in the OrderResponse message.
The next step is to define the Delivery message from the supplier in order to find the information that we need for further order processing. Outbound mappings can be done by using runtime variables and conversation variables, and in our case we utilize request_number from conversation variables. Outbound attributes have ServiceNow-like names to make it easier to understand. Lastly, Delivery process is successfully ended and all requests are closed.
ONEiO allows users to monitor all inbound and outbound messages that are sent through the system. We get this information in a neat form with access to detailed information about every message. Messages can be filtered (i.e. to find only error messages) in many ways by using the simple and intuitive filter bar:
ONEiO is a good use case for establishing an ordering and delivery process in ServiceNow. ONEiO simplifies and automates traditional integration development.
The platform helps solving customers’ and developers’ integration challenges in a more efficient and scalable manner. The feature which enables mapping of data messages from json to xml format together with the solid integration with Service Now, made it a perfect fit for our project. To achieve our goal, we used the ServiceNow Unifi application, which allowed us to create, monitor and manage outbound integrations.
By: Norbert Bokwa and Natalia Stasińska
Contact at us to find out how we can help your organization build a process in ServiceNow.