Custom Systems Integration

We offer solutions to various integration scenarios, from integration between multiple legacy systems inside the enterprise with services in the Cloud, to point to point integration of heterogeneous systems.

Integration Scenarios

We give some examples of possible integration solutions.

With the ever-growing demand of Software As A Service (Saas) in the Cloud, most companies are migrating part of their technological infrastructure and services to the Cloud. This poses a challenge when it is time to integrate all these services, as each service might have specific integration requirements.

We offer to develop a point-to-point integration of these services, o the integration using a middleware on those cases where it is required for the integration to comply with specific requirements such as specialized integration logic, data processing and data conversion, and integration orchestration according to proprietary business rules.

A lot of enterprises have legacy heterogeneous systems installed and running inside the organization (on premise) that needs to be integrated among them or with services in the Cloud. A typical scenario is the integration of an ERP system on premise with CRM software in the Cloud.

Most of these legacy systems don’t offer a web service layer, required to make the integration happen. We offer to create a web service layer on top of these legacy systems and thus make it possible to integrate with services in the Cloud.

Thanks to the creation of the web service layer, the services in the Cloud will be able to integrate with the legacy systems that remain still inside the organization, offering an abstraction layer with total transparency. This service layer can be build using SOAP and/or REST, depending on the specific requirements.

On some integration scenarios it is required to integrate third-party or legacy systems that do not offer a standard data input and output, making it difficult to integrate these systems with other modern systems or even participate in processes of integration orchestration. We offer the development of specialized connectors, allowing to interact with legacy systems through the standardization (by means of using modern protocols adapted by the industry) of their data input and output.

A typical case is the inclusion of an on premise legacy system to participate in an integration process orchestrated by a middleware such as BizTalk. If the legacy system doesn’t offer a protocol supported by the middleware and there are no existing connectors on the market then the integration cannot be implemented, unless a specific connector is developed for such a case.

With the ever-growing demand of SaaS services, most of these services offer a public API (Application Programming Interface) to integrate applications (being in the Cloud or on premise). This is the case of social networks, messaging services in the Cloud, CRM/ERP software, etc. which offer public APIs supporting either REST or SOAP to integrate with other applications.

Features

Our integration offering adapts to the specific requirements at hand, implementing integration with a combination of the following features.

Due to our variate offer of connectors it is possible to gather heterogeneous data, consolidate them and convert them to different standard formats required by other systems. We support any data type, native/legacy data (data codified in native format), structured data (where a data schema is available to represent and enforce the format of the data), semi-structured data (data where the schema is partially defined or there are no rules to enforce any rules on the data itself), and un-structured data (data that has no particular predefined schema).

Thanks to our middleware system it is possible to orchestrate integrations, offering the possibility to implement complex integration logic, data transformation, transaction queuing and error recovery.

It is possible to account for various integration modes: batch integration, real time and near-real time. These integration modes can be uni-directional (from source to target) or bidirectional.

The batch integration can be used in migration scenarios where the integration is only required once, or where the availability of the changed data do not constitute an important factor. An example of this is a case where the rating of a customer is calculated based on all the purchases made during the last month, which requires for the data to be calculated once a month.

A near-real time integration is mostly used in scenarios where the availability of the data changes is important, but some latency is tolerated on the refreshing of those changes. An example of this could be a process that automatically creates a maintenance contract triggered by a recent purchase by the customer, the purchase continues in a transparent way for the customer while all the contract creation processes are being executed offline, not necessarily at the same moment of the purchase.

And lastly, the real time scenario, where the data change availability is critical in order to continue with the operations. An example of this could be the purchase of an article from an inventory, if there’s no availability for such article at the moment of the purchase the operation cannot continue; in this case an on-line integration between the purchase system and the inventory system is required and there’s no tolerance on any data differences between the two.

Our services include the development of integration at multiple levels, being the most demanded those integrations that happen at the data layer, integrations in the application layer, or a combination of the two.

The integrations at the data layer, as its name implies, it is being implemented at the data base, using techniques that make use of stored procedures, views and data transformation through the usage of the data layer own tools. This level of integration is usually implemented in cases where the application doesn’t offer any tools for data input/output to external systems.

The integration at the application level is done in a level above the data layer, using the application own mechanisms for data input/output. The integration techniques will depend on the type of application to integrate.

Of course it is also possible to make integrations at multiple levels in cases where it is required.