Streamlining Browser-Based Approval Flows with Magic xpi

Using Magic xpi to implement browser-based approval flow.

Like many other enterprise-grade integration tools, Magic xpi is not designed to interact with end-users; its job is to move data efficiently between multiple systems and orchestrate business processes.

What if we find the need for user interaction? Integral designs an elegant solution! keep reading to find out how.

The Problem

At times, we come across xpi flow implementations where it may be necessary to interact with the user.

Traditionally, one would make use of a different set of tools other than Magic xpi to accomplish this. Suppose the requirement is such that this must be done in a publicly accessible mode. In that case, it may warrant investing in a web-based development tool that provides capabilities to create a web app, serve the required user-facing pages, and write back the response to the database, from where the xpi flow picks up the result of the user interactions.

One such scenario was presented to Integral when the customer wanted to implement a web-browser-based approval mechanism for their invoices. Still, without the overhead of having to look at “yet another tool” because that would open several threads like evaluation of different options, availability of development expertise, hosting related concerns, and maintaining the approvals system as a separate thread in addition to existing xpi flows.

The requirement was to make the approvals happen without disrupting the production environment.

The Solution – Overview

Integral designed a solution to make use of http requests to trigger the approvals flow.

However, it is not just triggering the flow upon receiving http requests but also having multiple re-entry points. These were needed for creating a seamless end-to-end user experience for approvals which interact with the multiple html pages involved.

Key Stages:

Invoices generated by the system and pending approval land in a table.
A part of the flow watches this table and triggers an email to approvers for pending approvals. The email contains the link that points to the xpi flow on the production server. A flow is listening for this http request.
Once the xpi flow takes over, it serves as an authentication page.
After successfully authenticating, the flow then serves a list of pending invoices.
The user can select one to see the details and the invoice pdf. This is constructed as another http request and send back to the xpi where yet another entry point is triggered using an endpoint.
The user can approve or reject the invoice along with comments, after which the user gets an option to return to other pending invoices list, which is one more endpoint for re-entering the xpi flow.
If there are multiple levels of approvals needed for an invoice, then the flow checks for the same and triggers an email to the next level approver with a link where the approver gets to see all such invoices that are pending for the level of approval for which this user is authorised.

Conclusion

User interaction is not something that is associated with xpi flows traditionally. However, with a unique requirement, there was a need to think outside the box and design a solution that would address the customer’s concerns.

Integral developed this solution, which importantly prevented the need for the client to invest in another tool, saving their time and money. The integration solution seamlessly fits into their existing range of software solutions and infrastructure.