10 facts about the Collenda API

Many factors play a role in linking an ERP system to an external software application. To ensure that a wide variety of ERP systems can be linked to our Open Credit 4.0 software suite, we have created a standard interface. Here we explain how it works.

The API improves the integration capability of our SaaS solution with existing software applications both on-premises and in the cloud. External systems usually have very different business data and technical specifications. The customer can now develop an integration layer between their own interfaces and our API themselves or with a partner. The complexity is significantly reduced in this way. The API also offers various methods for transferring files via WebService. In addition, the open interfaces avoid data silos.

The programmer on the customer side can interact with different business and technical facets of the application. We ensure access to high-level use cases, such as the import and export of customer master data and credit application and receivables data, including the associated case information on accounts and collateral.

  • High-Level Use-Case: This can be, for example, the command: “Give me the salutation text for partner xyz.”
  • Low-Level Use-Case: Access to low-level use-cases, such as querying individual business objects to connect the application to ERP or core banking systems, information service providers, DMS, print lines and portals, for example, is also guaranteed. For example, this could be the command, “Give me the master data of partner xyz.”

In principle, all common ERP systems can be docked to our software. However, these ERP systems usually have different requirements in terms of technology (e.g. response times, availability, security, data volumes, etc.) and technicality. Often, business entities or structures do not match. In this context, data mapping is an important topic. It is about linking fields of different databases. Mapping is usually the first step in data integration.

In addition, there is always the question of who is the “producer” (i.e., provider) and who is the “consumer” of an API. As a rule, the customer’s ERP system also provides APIs. In this case, it is the task of the integration layer to establish a connection between the systems as the consumer of several APIs.

The API can be used independently of the development environment. Since it is based on standard technologies such as HTTP and GraphQL, the WebServices can be integrated into existing or new software projects using any programming language. The data is transported via HTTPS. The data and query format is determined by a GraphQL schema. To support the development of integrations, we offer a cloud instance and interactive documentation. In addition, a Java SDK incl. examples is offered to support integrators (customers or partners) in the development of integration layers in the Java programming language in the best possible way.

We offer a so-called public/partner API and guarantee backward compatibility. This means that we ensure that further developments of our API continue to support all the functionalities of the previous version. This reduces the risk for customers of having to adapt their own API connections when we further develop our API. To ensure high availability of the API, we provide redundant infrastructure components in our cloud architecture, distributed across different data centers. Our API is therefore accessible in the cloud even if, for example, maintenance work is being carried out or a data center fails.

The API is basically intended for a wide range of software solutions, including portals, core banking systems, enterprise resource planning systems, accounting systems, regulatory reporting, external credit reporting services, external rating or decision systems, external workflow engines, printing lines, and also telephony, mail, and document management systems.

When using the interface, attention must be paid to data volume and response frequency. If there is a need to transfer large volumes of data between on-premises and the cloud, we offer an interface specially designed for mass data.

Risks exist in the areas of data transfer, data storage, and data access. Access to the interfaces is initially secured via OAuth, and data security is ensured by transport via HTTPS. Data is stored in encrypted form both in the database and on the application servers. Access to the infrastructure of the cloud environment for Collenda employees is strongly restricted based on a role concept and is logged.

Cloud computing (download whitepaper) offers the unique possibility of adding and also switching off computing power as needed. This is precisely what can be used depending on the load on the API infrastructure to ensure timely response to requests. In concrete terms, this means that the performance of the API can grow in line with our customers’ needs while maintaining data security.

For many of the measures we ensure in the cloud – such as security aspects, availability, and load-balancing of the IT infrastructure – customers must make their own arrangements if they want to use our solution locally. For this reason, we are noticing an increasing demand for the provision of our applications as SaaS. For on-premises customers, however, we will continue to make our application and interfaces available.

  • API: Programming interface for the integration / connection of Open Credit 4.0 into the customer’s IT landscape.
  • Integration: Programming work for integrating Open Credit 4.0 into the customer’s landscape.
  • IL (Integration Layer): Result of the integration.
  • Java SDK: Software Development Kit – used to simplify the creation of integration layers.
  • Inbound / Outbound: Direction of information.
  • Realtime: requests are processed immediately (typically < 2 – 10s).
  • Near realtime: requests are processed asynchronously or periodically to simulate realtime requests (typically 1 – 5 min).
  • Batch: requests are processed in a batch (typically overnight)
  • Trigger (from OC4 / from external): requests are triggered within the OC4 platform (e.g. by user interaction or automated workflows) /
    Requests are triggered from external systems.


Contact us

This might also interest you:

blank

Logistics: 8 tips against payment defaults

zombiesangst mittelstand

How zombie companies endanger the economy