Integrating external systems

What technology do I need to integrate my application with external systems?

Integration – what technology when?

Integration is a key element of many of the projects that our customers choose to build on the WEM platform. WEM offers a large variety of integration options, all available in every project and most easily setup, even by the most novice user. This blog highlights some of the integration standards available in WEM and when and where you may use them. For details on the how of using these technologies I invite you to read the blogs on that specific technology or attend our integration training listed on our training schedules.

On the MyWEM Start Page, a few Quick Starter Projects are provided (Example Service Consumer and Example Service Provider) that you can copy to your own Modeler Workspace to see all kinds of Integration Features in action with explanations.

SOAP

SOAP “Simple Object Access Protocol” is a highly standardized and self-documenting messaging framework, where everything you can do is strictly defined in a WSDL (“Web Service Description/Definition Language”) document. SOAP is a very rigid integration standard, which makes it especially easy to use for novice or non-technical users in WEM, because both systems integrating with each other have a pre-defined way of communicating and WEM can hide the really complex technical stuff. When using SOAP, the data exchanged is always in the XML format, but you’ll never know, as WEM does all the translation from and to XML into the familiar WEM datamodels. WEM can do both, Expose a Service (provide a service to let others connect to your WEM Project) and Consume a Service (to let you connect your Project to other external systems). Exposing and Consuming SOAP Web Services with a minimum of technical skills - that is typical for WEM. Integration between WEM Projects is possible and even fairly easy, using the SOAP standard. You use this option when integrating projects where you don’t want to just expose all data to the other projects, but rather need specific parts of data or specific modifications/preparations based on who is asking.

REST

REST “Representational State Transfer” is not so much a standard for integration but more of a standard architecture for creating web based API’s (“Application Programming Interface”). While that makes REST very flexible, it also means you need more technical know-how to integrate your WEM Project with other systems. The flexibility of REST also means you can choose your own data formats. Most often, JSON is used, but XML, CSV and others are also possible and supported by WEM. WEM can do both, Expose (provide a service to let others connect to your WEM Project) and Consume (to let you connect your Project to other external systems) REST Web Services, but both require some technical skills and knowledge of data structures like JSON. To aid in consuming the REST services exposed by your WEM project, the WEM Modeler generates Documentation with examples in both JavaScript and TypeScript with all the specifics of your exposed services. The REST features in WEM are best used when integrating with an external application that already offers a REST based API.

Consuming an external REST service with JSON data, can be actually pretty easy in WEM, using the Http Request Node to execute the call, using the Export Json Node to easily generate the Request Body and using the Import Json Node to easily map the results in the Response Body to your WEM fields.

Do check the aforementioned Quick Starter Projects for examples!

When you expose a webservice in WEM, the service is automatically provided for SOAP and REST consumers! You only have to define the service once, with methods, input values and output results!

OData

WEM currently supports OData V3 This is important to know, as external parties may support other versions (V2 or V4) which are NOT compatible.

The OData standard is in many ways the most flexible and easiest integration option for WEM, you can expose all your data from your WEM project and have any other application supporting the OData standard interact with that data, where reading, updating and writing are all possible. WEM can also consume OData exposed services. These capabilities are offered as a standard feature on many (if not all) applications from Microsoft, SalesForce, PowerBI, Oracle and many others. To use the OData integration option you don’t need much technical knowledge, but there are limitations around security and data integrity that you should consider, as well as possible limitations on filtering options or large data transfers. Some of the many interesting uses of the OData standard is integrating your WEM project with Microsoft O365, CRM systems or other administrative applications.

HTTP(s)

HTTP “Hypertext Transfer Protocol” is what most people call a website, plain and simple it’s the World Wide Web Browser way of requesting data and receiving responses. Using WEM you can easily just execute a call to any website and retrieve the information that would normally be shown on the screen of your web browser and process that information in your WEM project. While this is not the nicest way of integrating, especially from a technical perspective, sometimes applications offer a nice human readable web interface but no fancy API, or maybe the API comes at an additional cost. The raw HTTPS (please, use the secure version with the “S” at the end!) is your solution of last resort when integration with an application or website that doesn’t offer integration with SOAP, REST or OData formats.

File Import/Export

Using WEM you can import and export a host of different file formats. Some of these, like PDF, are mostly read-only, others like pictures can be edited by using some of the more advanced Widget features WEM offers and yet others are fully machine readable. WEM supports many different formats like CSV, Excel, XML and JSON using the available import and export nodes; as well as the ability to generate documents as Word (docx) or PDF using the specific Process Nodes. The format you use is mostly dictated by the data you want to import or export and the available formats in the applications you want to integrate with. Sending an invoice to a customer? Show the invoice in the body of the email as HTML and attach a copy in PDF. Want to do statistical analyses and your statistics application doesn’t support OData or other integrations, use CSV (or Excel, XML or JSON depending on what they do support). Want to import a large list from your previous administration built in Excel, use XLSX or CSV. The file integration is most often used when batch processing with human intervention is required, this is not a commonly used integration for application to application interaction.

Cheat sheet