Flexible Integration Options to Support Next Generation Low-Code Applications
Flexible Integration Options to Support Next Generation Low-Code Applications by Andrej Koelewijn
Integration has always been essential to application development. But the topic hasn’t taken much of the spotlight in the marketplace for developing apps until now. As cloud native and “as a service” software options mature, APIs that exchange data, trigger events, and orchestrate workflow processes between disparate applications become critical.
At Mendix, we’ve made investments in the platform to make it easy to connect applications and services in a variety of ways, including REST services. And while building REST APIs or REST web services for applications to talk have become standard, it’s important to recognize other web service protocols.
Standardized frameworks and APIs remain valid options depending on the problem you’re trying to solve. Let’s spend some time identifying the use cases where Mendix plays a role in integration, the guiding principles for building integrations with Mendix, and how the platform solves integration challenges to enable your enterprise.
Identify the use case for integrations
Mendix offers various protocols, frameworks, and APIs for integrating systems with low-code Mendix applications and between disparate software solutions. But before you pick an integration technology, you must identify the use case. The use case will help inform the decision you will make. Let’s go through the most common integration use cases and the technologies used to satisfy them.
Extending legacy systems
A common use case for Mendix is to build modern UIs and mobile apps on top of legacy systems. You still see a lot of SOAP-based web services when connecting to legacy systems. Mendix’s web-service support for mapping complex XML messages to Mendix entities will allow you to use these systems from your application quickly and seamlessly.
It’s also common to build apps directly on top of legacy databases or even custom protocols. Mendix offers a Database Connector to run SQL queries directly on existing databases. You can use the Connector Kit for custom protocols to provide access from Mendix applications quickly and easily.
Using third party services
Increasingly, software components and functionality are offered as a service. All the large cloud vendors offer many interesting services, from text to image recognition, from address validation to complete business process automation. The majority of these use REST to expose these services, although some SOAP technology is still being used.
Many companies participate in digital ecosystems. APIs to expose data, algorithms, transactions, and business processes play a crucial part in this goal. APIs enable an independent group of enterprises, people, and things to collaborate on a standardized digital platform. REST is the primary way to implement these APIs.
Using microservices architectures to build complex solutions
To achieve speed and agility in your software development process, separating your solutions into small components that can be developed and operated by small autonomous DevOps teams has become essential.
Sharing data and logic between multiple apps often takes significant effort to implement. Mendix helps you by generating most of the required APIs based on your microflows and domain model entities.
Decoupling your components using a message bus or iPaaS will bring additional benefits like improved uptime and scalability for microservices. Mendix works well with most commercial messaging products. Modern iPaaS platforms offer publish and subscribe functionality based on REST protocols. Real-time push-based messaging is provided through REST webhooks usually.
Microservices best practices promote the concept of smart endpoints and dumb pipes. In practice, this means that your message bus is only responsible for transporting messages between apps. The apps themselves need to be able to translate a message into any format they need. Mendix’s Import- and Export-mappings enable you to easily define in a visual way how to convert message formats from one app to another.
Backend system for bespoke frontend and mobile low-code application development
Developers of mobile apps usually need a backend to store their data and integrate with backend systems. Using Mendix’s ability to generate Rest APIs for domain models, you can have a backend for your mobile application development in 5 minutes. No need to spend a lot of time building a backend and no need to learn another backend language (and database technology) just to store your mobile data.
Mendix is not limited to just storing data for your applications. Because of its strong support for logic and integration, we see customers using Mendix as a Digital Integration Hub. The Mendix-based backend retrieves data from other backend applications and services, handling data transformation and validation.
And best of all, creating administrative web pages to manage your back office processes is a piece of cake with Mendix. Building these back-office webpages usually takes a lot more effort with specialized mBaaS solutions.
As mentioned above, one major goal of our integration facilities is to connect to external systems. Through low-code application development, we aim to make this as productive and straightforward as possible. However, when dealing with external systems, productivity is not enough. Control, agility, and collaboration are essential aspects to consider.
When dealing with systems that are not under your control, having control over integration details can be very important. You need to adjust to the external system, which is often not implemented according to spec or built using outdated practices.
You need a flexible and straightforward way to convert messages between external systems and your Mendix application.
In Mendix, this is handled with mappings. You can define import mappings to convert received messages into Mendix objects. When sending objects to external systems, you can convert them using export mappings. Mappings work both for XML messages as well as for JSON messages. Mappings are reusable, meaning that you can use them for Web Services, REST services, and connector kit integrations.
The following screenshot shows an import mapping where an XML or JSON message containing orders and order lines will be converted into Order and OrderLine objects.
Speed is not just about raw productivity but also about changing your applications quickly and easily. When external systems depend on your services, or vice-versa, being able to modify your application without impacting external dependencies is critical. Two essential tools will help you here: versioning of APIs and explicit contracts about the messages exchanged.
To ensure the messages you exchange remains the same, you can define these messages using message definitions. Depending on the use case, an XML-schema, a JSON structure, or a message definition started from one of your domain model entities can be employed. When you make changes to your mappings that aren’t compatible with your message definitions, you will see a consistency check.
The following screenshot shows a message definition started from an entity. If you have associated entities, you can include these to define the aggregate message, e.g., orders with order lines.
Versioning is built into REST publish. You can specify a version for your API and make it part of your endpoint address. When you need to provide an API with different behavior, you provide a new version simply by copying the original definition and changing the version number. This action allows you to run two versions side-by-side until everyone has migrated to the latest version.
Integration usually requires collaboration with other people, both inside your organization and outside as well. We aim to make this as easy as possible by providing visual mappings to define how to convert external data to internal data, for example. The low-code application development platform’s visual UI enables a collaborative user experience with anybody in your organization, even non-technical citizen developers, which furthers your organization’s rapid application development initiative.
Another tool that facilitates collaboration is the automatically generated documentation and contracts for your services, so others can easily understand and use them. Every REST API you implement will automatically include an OpenAPI document describing all your API’s resources and methods. If you include documentation and example values in your message definition, as shown in the previous section, these will also be included in your OpenAPI documentation. This will make it very easy for your user to start using your API.
Similarly, every web service built with Mendix generates a WSDL-based documentation page.
Now that we’ve looked at the main use cases for integration and reviewed the guiding principles for building integrations, let’s go through the main tools for implementing these in Mendix. Here’s the list:
- Web services — Mendix provides out-of-the-box support for publishing and consuming SOAP-based web services.
- Rest services — REST publish and consume for microflows and entities.
- oData — Publishing entities for use in BI and data analytics tools based on the OData standard.
- Connector Kit — Integration through custom Java logic.
- Connectors — Custom integrations using the Connector Kit available through the App Store.
Mendix supports both publishing and consuming web services:
- You can publish microflows as web service operations.
- You can consume web services by importing their WSDL contract.
Creating a web service is as easy as selecting “Publish as web service operation” in the microflow editor. When you turn any microflow into a web-service operation, the microflow return value and all input parameters will automatically be converted into input and output messages for the operation.
You have full control over the message, and you can select which attributes to include and what names to use, as illustrated in the following screenshot. These features allow you to ensure the contract with the outside world is stable while still making changes to your application. And speaking of contract, using this information is enough to automatically generate both the WSDL and the documentation.
When you have a WSDL, either from a Mendix application or a 3rd party application, you can easily import it into your Mendix App. All you have to do is create a new “Consumed Web Service” document, specify the location of your WSDL, and you’re good to go.
You can call any operation in the consumed web service using the Call Web service activity in a microflow. When calling an external web service, you can use import and export mappings to ensure your domain models are easily converted to and from any messages you need to exchange with the service.
Import and export mappings offer a powerful way to convert external data to Mendix objects and vice-versa. Some of the supported features include:
- Automatically detect and create associations between objects.
- Support for inheritance and other complex XML types.
- Generate the required domain model entities from the WSDL or XML schema.
- Create new objects or object existing objects.
- Microflows can convert attributes.
- Specify which attributes in the message should be treated as key attributes.
- Support for complex XML schema definitions like the Acord standard.
These mappings can be reused for XML and JSON and web services, as well as REST and connectors.
We are very proud of what you can do in Mendix with REST publish. We can now safely say that Mendix is the easiest and most productive way to create APIs. Users can:
- Generate full Rest API for an entity from the domain model.
- Generate full Rest API by dragging an entity from the connector.
- Generate default message definition for an entity by dragging it from the connector to a message definition.
- Generate default mappings from a message definition.
With these productivity improvements, you can now create a REST API for your domain model in literally seconds, as illustrated below.
Most new services are using REST instead of web services these days. Using REST requires a small shift in the design of your services. Web services are about calling and providing access to remote logic. In REST, you design a data model that external apps can use. Objects in your domain model are called resources. The operations on your resources are standardized:
- Read or find one or more existing resources (GET)
- Create a new resource (POST)
- Change an existing resource (PUT)
- Delete an existing resource (DELETE)
You will also see this approach in contracts for REST services like Swagger and OpenApi: first, the resources will be listed, and then the operations on these resources.
The Mendix REST publish functionality follows the approach used by OpenApi, where you define your resources first and then the operation on those resources. You have complete control of your REST API because you define the resources, the messages exchanged, and the microflows that implement the operations.
Alternatively, you can let Mendix handle all of this automatically. Just expose your entity from your domain model, or drag an entity on the resources section of a publish REST document.
Everything required will be generated for you, including security. Your REST API automatically uses all the security rules you define on your entities.
Whether you want full control of the API you implement or just want to generate a backend for your mobile application in 5 minutes, Mendix can do it.
Looking at the implementation of your REST operations, you can use any microflow to implement a REST operation. Mendix will automatically detect the parameters you need and any objects that require an import or export mapping. These operations can be specified in the Operation dialog. You can also use ‘send’ and ‘receive’ binary data or ‘file document,’ for example, if you want to provide an operation to retrieve a pdf document.
The following screenshots use the optional ‘httpResponse’ parameter, which you can use to override the HTTP status code or status message. If required, you can also specify that you want access to the HTTP request, for example, to determine the value of HTTP header values.
As shown earlier, Mendix will automatically provide an OpenAPI contract and documentation page for every REST service you create. If you offer example values in your message definitions, your REST service users only have to push ‘Execute’ to see the result of calling your service. We can’t make it any easier than this.
Calling a REST service is also simple. First, you define how the external resources you will use look by creating a message definition. The easiest way is usually to create a JSON structure by copying and pasting an example JSON message. Mendix will automatically determine the structure of your message and the applicable attribute types, as illustrated below.
Next, define mappings to import and export data to the external REST service. This action is similar to the example above. One feature not yet mentioned is that you can generate Domain model entities if you do not already have the appropriate entities, such as when you have defined a message based on some example JSON.
Finally, use the “Call Rest” activity in microflows to call the REST API. This is simply a case of providing the URL of the API, and in the request and response tabs, you can define which mappings you want to use.
Mendix currently provides OData in the modeler as an integration facility for a specific use case: providing Mendix app data for analytics. Next to this, Mendix also provides SAP integration based on OData, but this is based on connector kit technology, as described in the next section.
OData provides a similar interface that you may expect from a database. It has insert, select, update, delete functionality on resource. OData achieves this by standardizing a data language on top of REST so that all client tools understand upfront how to work with the data you expose.
The data analytics tools that support OData range from Microsoft Excel to Tableau, to ETL tools, to basic query tools like LINQPad and statistical analytics tools like R. This means that you can expose your data from Mendix once, and all these tools can directly work with the data within your app.
To expose your Mendix data through OData, select “Expose as OData resource…” on your entity in a Domain model.
Next, you will be able to specify which attributes you want to expose. You can also specify who can access this data. Of course, all entity access rules set on your domain model entities still apply when retrieving data through OData.
You can now open the exposed entity directly in a tool like Microsoft Excel or PowerBI and always have up-to-date information from a Mendix application.
Find more information on Mendix OData support and how to use R to gain insight from the data in your Mendix apps.
In case one of the out-of-the-box integration facilities doesn’t fit your needs, you can use the Mendix Connector Kit to implement a custom integration. The connector kit enables you to implement custom microflow activities using the Mendix Java API.
You can reuse most 3rd party java libraries to provide any integration you need. Mendix completely integrates the microflow activities you implement into the toolbox so that any Mendix developer can use them without Java knowledge.
To create a custom integration with Java, create a custom Java action to create a Java source file. Here you can provide your Java implementation or call into existing Java libraries. You can also define how your activity will show up in the microflow editor toolbox, as illustrated below, to ease the use of your customer microflow activity by other developers.
Users of your custom integration will now see the activity show up in the Microflow toolbox, like any other microflow activity.
If you want other projects to benefit from your custom integration, you can publish the source module to the Mendix App Store.
Find more information on the Mendix Connector Kit:
A large number of these custom connector kit-based integrations already exist in the Mendix App Store.
SAP OData connector
The SAP OData connectors enable you to build Mendix applications on top of SAP quickly and easily. The OData model creator will generate a Mendix domain model based on what you have exposed in your SAP API Hub. As a result, any customizations to your SAP APIs will also be included in your Mendix application.
App Store links:
Using the database connector, you can execute SQL queries and stored procedure calls on existing databases. The connector will execute the query and convert the retrieved data into Mendix objects. The App Store also contains an Oracle connector with support for Oracle-specific extensions like pl/SQL procedures, ref cursors, and user-defined types.
App Store link:
Apache Kafka connector
Apache Kafka is a distributed streaming platform that allows for a high-volume exchange of messages between various applications. It’s also used to process—for example—IoT sensor data. Using the Kafka connector, Mendix Apps can send and receive messages through Kafka.
Machine learning and cognitive connectors
Several connectors in the Mendix App Store allow you to use machine learning for specific purposes, including identifying images and text, automating conversions with chatbots, and detecting emotion in text.
Redis is an in-memory database used to build a distributed multi-instance application. Redis can be a data cache and message broker as well.
App Store link:
- Redis connector: https://marketplace.mendix.com/link/component/3087
Here are some other connectors used with IoT data:
- MQTT client: https://marketplace.mendix.com/link/component/3066
- AWS IoT connector: https://marketplace.mendix.com/link/component/2868
- KPN Lora connector: https://marketplace.mendix.com/link/component/2747
As the demand for applications grows, the need to connect them will grow to support the diversity of use cases. Mendix offers flexible integration options tied to guiding principles that make new connections easy to build, manage, and expose to various systems and services within your organization. Providing developers with the right tools and options to help them build integrations gives them the flexibility they need to create and connect apps with speed, collaboration, and control.
This post has been updated. It was originally published on July 19, 2018.