Concur integration with Informatica Cloud: A technical review

Concur is one of the industry’s most widely used travel and expense management solutions, used by more than 32,000 organizations globally. For companies that are implementing or have implemented Concur, one critical step necessary to fully unleash the power of the platform is the integration process.

After implementing Concur, companies often spend a large amount of time on tedious manual work, such as adding new users on new hire events, user off-boarding, manager changes, department changes, etc. These “maintenance” tasks seem trivial at first, but they actually require a major time commitment from Concur administrators, who could be focusing on other critical tasks. Besides, managing Concur’s interaction with other systems, such as HR or financial ledger platforms, introduces more challenges, as these tasks are not straightforward and solutions are not directly provided by any of the applications involved in the integration.

Does this sound familiar? Many companies experience these challenges on a daily basis. Without a sound integration solution in place, managing such a powerful and efficient travel and expense system can be challenging.

Informatica Cloud is the industry-leading integration platform-as-a-service (iPaaS) and data management solution, designed to connect with enterprise-ready data and applications across cloud, on-premise, big data, social, and mobile environments. We are proud to be an award-winning Informatica Partner (Outstanding Partner of the Year 2016, Cloud Emerging Growth Partner of the Year 2015), with experience implementing hundreds of integrations. In this article, I’ll share our experience and the technical insights we gained in leveraging Informatica Cloud for successful Concur integrations.

Understand integration goals

When it comes to data integration, regardless of the applications involved, your first task is to understand the business and technical goals you want to achieve. You’ll also want to consider the other applications that will have to integrate with Concur.

To better understand the business goals of the integration — and the challenges involved — consider the following questions:

• What business value (or return of investment) will this integration bring, in both the short and long term?
• What is the current process we’re looking to integrate? What are the pain points?
• What’s the end state of this automated integration? Are we looking to roll out the integration in phases?

Gaining a better understanding of your business goals and how they align with technical needs is an important first step in designing a solid integration approach. To understand your technical needs, consider the following questions:

• What are the data objects involved with the integration? Specifically, what types of data (data attributes on these objects) are involved? Are they structured, semi-structured, or unstructured?
• How should the integration be triggered — real-time, event-based, scheduled, or on-demand?
• What’s the size of the data in scope? Will we need to run the integration in bulk mode? 
• How do we want to be notified on the outcome of the integration, and what information should this notification include?
• How would this integration recover from exceptions — human intervention, auto-recovery, or a combination of both?

Answering these questions will help you further define the scope of the integration process and narrow down your design options for satisfying your requirements and achieving your goals.

Match the approach to the need

Let’s review the integration options around Concur — the thoughts behind each option, the reasons why each should be used in different scenarios, and how each ties back to the business and technical needs we discussed in the previous section.

Concur connectors by iPaaS

Most iPaaS offerings provide pre-built application connectors that are ready to use — an important consideration when choosing your platform. Informatica provides two versions of Concur connectors, ConcurV1 and ConcurV2.

It’s rare for a provider to offer multiple versions of connectors at the same time; however, with Concur connectors, there is a good reason for it. Most connectors are built by the iPaaS vendor on top of the API offered by the solution provider. Concur, as the solution provider, has multiple versions of its API (Concur API Portal) running at the same time for different sets of functions. That’s why we see two versions of Concur connectors from Informatica.

It’s essential to understand which Concur data objects are in the scope of your integration, as you can then evaluate the right connector for the right operation for these objects. For example, for the User object in Concur, different API endpoints offer different sets of functions:

• Version 1 API offers three operations on the User object: read, create, and update. It also supports updating the user password (separate from other User attribute updates).
• Version 3 API offers only the search operation on the User object. (Note: There is no Version 2 API for the User object.)

As noted, the two versions of API for User objects are designed for different services. Version 3 API provides robust search capability, while only limited user information can be retrieved in the output. Version 1 API on the User object is not as performant as Version 3, but provides a full span of user information with read, update, and create capabilities. To match the Concur connectors, Informatica wraps the Version 1 User API in ConcurV1 and Version 3 in ConcurV2.

As you can see, Concur Rest API is the backbone of all Concur connectors. However, since Concur connectors do not inherit all API functions, they pose several limitations:

• Connectors lack support for custom attributes. Going back to the example of the User object in Concur, if you create a user with additional custom attributes that are not listed in the API reference doc, the connector will not work.
• The connector can only deal with one object at a time. If you update users and user profiles in sequence (a common use case), the connector will not work.
• Connector provisioning always incurs a licensing cost.

Concur Rest API

If you encounter limitations using Concur connectors for the above use cases, you may want to work with the Concur Rest API directly and design customized solutions to address your specific use cases.

Advantages of working with the Concur Rest API include:

• Custom attributes: It’s common to set up custom attributes in Concur to fit records into your business use cases, which leaves the Concur Rest API as the only option for automating processes.
• Working with multiple objects in parallel or in sequence: Most business processes involve multiple data objects. For example, for a new hire event, three objects need to be created: a user, a user profile, and a travel profile. The ability to orchestrate multiple object operations is critical for governing data integrity in an automated manner and keeping future maintenance work to a minimum.
• Cost reduction: As I mentioned above, each connector comes with a cost. Using generic connectors and the Concur Rest API or custom connectors (discussed in more detail below) are good alternatives to expensive application-specific connectors, leading to long-term savings.
• Performance benefits: With Rest API, you can choose to deal only with the data of interest instead of all data exposed by the API. This reduces the data size and results in improved performance of the overall transactions.

Informatica offers two options for implementing Concur Rest API:

• Informatica Rest V2 Connector: This generic connector can be configured and set up to work with any Rest API endpoint. It supports a variety of authentication options and utilizes swagger definition to configure the data objects and operations involved in the transaction. The Rest connector can work as a source, a target, or a mid-stream in any typical integration operation of the Rest API call, such as read, write, or delete. It automatically converts hierarchy data from the application to relational data or vice versa, which can subsequently be used in downstream applications. (I recently published a technical talk with in-depth focus on the Rest V2 connector.)
• Informatica Cloud application integration (ICAI, formerly Informatica Cloud Real Time): This option allows you to construct the Concur Rest API as a service in a service-oriented integration process, encompassing event processing, service orchestration and process management. ICAI allows you to streamline complex business use cases in a workflow-like process and invoke them in real or near-real time. As an output of the integration process, it also provides flexibility around custom error handling and customized notification content.

Concur SFTP

Concur SFTP can be used for both inbound and outbound integration, for data imports as well as exports. It is also a viable option for bulk data loads and extracts.

Concur SFTP works as either a source or a target within Informatica cloud integration and also interacts with other applications. You can implement it as a service in Informatica Cloud Application Integration and monitor it in real time, invoking an integration process upon a new file dropped on the SFTP site.

Although information on the data objects that the SFTP supports is not publicly accessible, it’s clear that not all objects are supported. Concur SFTP is also an option with a relatively low cost.

Concur app center connectors

Concur manages a list of connectors in the Concur App Center, most of which were created by travel and expense partners. These connectors are designed mainly for consumers to import their personal data and aren’t suitable for enterprise-level application or system integrations.

Avoiding common caveats

To conclude this overview, I’d like to share some caveats, or “gotchas,” that can complicate Concur integrations.

Skipping the sandbox

To save on cost, some companies choose not to have a sandbox and to provision only the Concur production instance. This can create a problem, as Concur could be dealing with multiple sets of data that could become corrupted, and other integrated systems generally have both production and sandbox instances. By omitting the sandbox, you run the risk of production data becoming corrupted. Besides, certain objects in Concur cannot be deleted but only be disabled or set to “inactive.” This increases the amount of redundant, “noisy” data, which can be difficult to manage and may affect data integration with other systems, as data integrity will be compromised.

There is no ideal solution in this case other than getting a sandbox, even temporarily for integration design, development, and testing. Otherwise, specific considerations need to be taken on architecting and design to minimize the injection of redundant data — such as introducing a data flag to categorize individual transactions (update on existing data vs. create with new data) — so that we can reset these data accordingly after development and testing. Additionally, good planning is needed for test data to minimize the impact of the noisy data and avoid impacting data integrity.

Custom fields created in a web browser

As we discussed above, it’s a common practice to customize the Concur application by adding custom data fields, which administrators can do through the Concur application in a web browser. However, not all custom fields created by web browsers are necessarily supported right away by the Concur Rest API. As a result, the API may not support all the custom attributes that are in use at any given time. You can submit a support ticket, but it could take some time before Concur releases an API update.

API changes

Finally, the backbone of application integration is the underlying API, which evolves over time. It could definitely affect your integration if the API version is deprecated or even updated with different behavior during the process. Be mindful and stay on top of new API releases.

If your organization is planning to implement Concur, keep in mind that the integration process is a vital step that must be carefully and mindfully planned. Begin by clarifying your business goals and technical needs, then select the approach that will fit your requirements (and be sure to avoid the “gotchas”). Executing a well-designed integration will help ensure that your organization gets the most benefit out of this powerful platform.

Author JayJay Zheng is a Technical Director, where he is instrumental in providing the best technology experience and expertise to Fortune 500 clients. He is also a Oracle Ace and Informatica certified Integration Specialist, and is a regular contributor to the advancement of transformative digital technology.