We’re delighted to share the third instalment of our webinar series, Low-code 101. In this episode, host Laura Ritchie discusses integration issues with another of our Solution Architects, Richard Kelly.
Integration is a key area where we encounter many questions in the early stages of Low-code adoption. All businesses need to ensure that their existing tech and legacy systems will integrate with any new software that’s introduced. It’s actually a key strength of MATS Low-code and often one of the major drivers for implementing Low-code.
You can find this webinar, and the other episodes in the Low-code 101 series, here. A transcript of episode three, spotlight on integration, is laid out below.
Laura: Hello and welcome to our third webinar. I’m Laura Ritchie, a Marketing Communications Manager and today my co-presenter is Richard Kelly. In this “Low-code 101” series, we are talking through different aspects of Low-code and today Richard will answer some of the integration questions you may have. Thanks for joining me today Richard…
Richard: My pleasure Laura and hello to everyone listening…
Laura: So, integration is a subject that many of our customers speak to us about. All businesses, including ours, have legacy systems or existing tech that needs to talk to each other to ensure end-to-end processes are efficient.
Richard: Yes, it’s a real headache when systems don’t work with each other – we often hear horror stories of lots of manual processes to bridge the gaps. We even hear of data being re-keyed between systems with all the problems and consistency issues that involves. The other big problem people have is that the same information quite often appears in multiple systems – for example customer details – and no one is quite sure which system is updated, when and by who!
Laura: So how can Low-code help with these challenges?
Richard: Low-code allows businesses, which may or may not include the IT department, to rapidly develop the tools necessary to run their business without relying on spreadsheets! By saying the IT department is optional, I mean that, depending on the skills and resources available, IT may choose to provide the governance for the solution, with business managing the development of applications. Or, IT may also undertake the application development.
Laura: Let’s get into the specifics on integration…
Here’s our plan for today’s session:
- Integrating external solutions
- Single record
- The use of master data
- Integration with other enterprise applications
APIs and Enterprise Applications
Laura: So, Richard, are you often asked for a list of APIs – can you explain what MATS can work with?
Richard: MATS has a number of different integration points, most of which you will find in the Data Exchange section of Build Studio. These cover the data file import and export capabilities you would expect – with text files and Excel workbooks supported.
We can configure data separators, header and footer lines and reformat rows or individual fields prior to processing them.
This proved handy recently when an export from one system produced a date in an unusual format, which needed to be amended before MATS recognised it.
We have the ability to copy files to an SFTP (secure file transfer protocol) server or retrieve files from an SFTP server. Using rules can combine this with the data import capabilities and ingest the records.
The next integration point is between MATS applications – providing read only access to data on one MATS application from another. It’s great for reference data or Master Data.
This is known as Remote objects – with one MATS application hosting data which can then be synchronised to one or more additional MATS systems. We can even limit which properties and relationships can be exported.
The final means of integration is the use of APIs with a whole host of different options.
Laura: Can Low-code integrate with enterprise applications to provide a complete solution?
Richard: MATS has APIs for a number of regularly used applications built into the platform. These include Experian, Salesforce, Zendesk, Adobe eSign, Docusign and MS Dynamics.
However, these are only a small number of the systems our customers use, so we also provide a generic adaptor to allow integration with thousands of other solutions. This allows control, using the MATS interface, over authentication, headers, data parameters and multiple different functions within an API.
There are a couple of very good documents on our community portal with details of setting up APIs, including a walk through of a real case with IBM Watson text translation, check the Feature Notes in the Resource Centre.
Let’s look at a simple demo of MATS here, where I create an API connection, telling the system where we are going to communicate.
Server Data and Master Data
Laura: That covers MATS accessing other systems, but what about other systems accessing MATS?
Richard: Yes, we can configure MATS to server data as well. Either for generic external systems or for other MATS systems. The process is very similar to what we have just described. Set up an API endpoint and then set up the functions to be called.
Laura: We have started to touch on the concept of sharing data – can you expand a little further?
Richard: Master data is the core data that is essential to operations in a specific business or business unit. The kinds of information treated as master data varies from one industry to another and in companies within the same industry.
It is the capability of having just one “Source of Truth”. This means that we don’t need to replicate and update data in multiple places.MATS and the API capabilities is most of the issue – one source of data. It’s now only legacy systems that don’t communicate well, that we need to worry about.
Laura: With all the data in one place and accessible, what security measures need to be in place?
Richard: Every MATS API access, inbound or outbound, can have a number of security measures in place. In most cases, these would include authentication, either a simple user id and password encoded, or more complex authentication scheme like OAUTH, requiring numerous parameters and run-time creation of an access token.
We also have the option of defining a firewall profile for the API Endpoints where MATS is the server. This firewall profile can include blacklist or whitelisting IP addresses as well as restricting access based on domain names.
Laura: This all sounds very technical…
Richard: Unfortunately, this is one of the more technical areas of MATS. It normally relies on both IT and someone knowing what is on the other end of the connection to get it going. Once it is in place, there should be little or no change required.
I hope I have avoided too much jargon and given a flavour of just what is possible using the integration and data exchange capabilities of MATS.
Laura: Thanks for your time Richard, I’ve certainly learnt a lot! Hopefully that has covered a lot of useful points for you as well.
If it has whetted your appetite, you may want to revisit our earlier “Low-code 101” sessions on security and the fundamentals, plus our Podcast series, Life in Low-code, is really interesting. Don’t forget to follow us on Twitter or LinkedIn too.
We’ll be doing another session soon which will put building the business case for Low-code under the spotlight. From Richard and me…. Goodbye!
Our next episode of “Low-code 101” will put the business case under the spotlight. This will be available in the next few weeks.