iPaaS Value

Alumio Deep Dive: A Basic Transformer

A transformer is a reusable building block, and the parts that make up a transformer are reusable and precreated for Alumio users.

Alumio Deep Dive: A Basic Transformer

Data sent from one application to another needs to be made compatible to be accepted. The exchange protocol and file types can be different (SOAP, REST), but so can the specific required information (ex. filter out unneeded information or add a new required field), the way values are described (ex. "red"/"blue"/"green" versus "R"/"B"/"G" versus 0/1/2) and other similar - but critical - details.

Alumio calls this transforming data, and the building block for that a transformer. A transformer is a reusable building block, and the parts that make up a transformer are reusable and precreated for Alumio users. It is the most powerful and flexible part of Alumio that provides non-programmers a quick start to create a reliable solution to connect applications.

Orders example

Suppose you are using Alumio to transfer orders from your e-commerce website to a Warehouse Management System (WMS), so that products can be shipped and your customer is satisfied. What you may find, when you ask your online shop for the latest orders, that it gives a list of orders paid as well as those not yet paid. Surely, the customer should pay before receiving items!

A simplified list of orders, provided by the e-commerce website:

Magement-Data-from-Online-Shop.png

When the state is "processing", then it should be provided to the WMS, otherwise it should be skipped until it is paid.

Alumio can apply a transformer to this list. Such a transformer can look like this:

Figure: transformer with explanation
Figure: transformer with explanation

Alumio contains a transformer tester to see how it behaves when provided with actual data:

Magement-Transformer-Tester.png

In the image above you can see how the second item of the list was removed and the other two items were kept. It works as expected and can be implemented in a Alumio installation of the client needing this solution.

In a follow-up post we will discuss the different kinds of transformers available in Alumio. Already shown here is filtering. Others kinds are: changing data, mapping data from one set onto another, moving nodes, copying nodes, transforming on conditions, and chaining multiple transformations together. Make sure to subscribe so you don't miss it!

Data sent from one application to another needs to be made compatible to be accepted. The exchange protocol and file types can be different (SOAP, REST), but so can the specific required information (ex. filter out unneeded information or add a new required field), the way values are described (ex. "red"/"blue"/"green" versus "R"/"B"/"G" versus 0/1/2) and other similar - but critical - details.

Alumio calls this transforming data, and the building block for that a transformer. A transformer is a reusable building block, and the parts that make up a transformer are reusable and precreated for Alumio users. It is the most powerful and flexible part of Alumio that provides non-programmers a quick start to create a reliable solution to connect applications.

Orders example

Suppose you are using Alumio to transfer orders from your e-commerce website to a Warehouse Management System (WMS), so that products can be shipped and your customer is satisfied. What you may find, when you ask your online shop for the latest orders, that it gives a list of orders paid as well as those not yet paid. Surely, the customer should pay before receiving items!

A simplified list of orders, provided by the e-commerce website:

Magement-Data-from-Online-Shop.png

When the state is "processing", then it should be provided to the WMS, otherwise it should be skipped until it is paid.

Alumio can apply a transformer to this list. Such a transformer can look like this:

Figure: transformer with explanation
Figure: transformer with explanation

Alumio contains a transformer tester to see how it behaves when provided with actual data:

Magement-Transformer-Tester.png

In the image above you can see how the second item of the list was removed and the other two items were kept. It works as expected and can be implemented in a Alumio installation of the client needing this solution.

In a follow-up post we will discuss the different kinds of transformers available in Alumio. Already shown here is filtering. Others kinds are: changing data, mapping data from one set onto another, moving nodes, copying nodes, transforming on conditions, and chaining multiple transformations together. Make sure to subscribe so you don't miss it!

Solve your shortage of IT personnel
Setup and maintain low-code integrations by less technically skilled employees, freeing your senior developers to solve other complex coding problems.

Leave support to facilitation roles
The easy-to-use interface of the iPaaS, coupled with its Monitoring & Logging system that automates error detection and troubleshooting, requires minimum tech support.  

Less overruns
The iPaaS helps highlight and eliminate roadblocks to better customer satisfaction. It also makes integration data flows visible for users and project managers to review and optimize together.

Bypass the hassles of custom coding with our iPaaS
Instead of investing significant money and time in developing your own integration solution, simply get an iPaaS to create, manage, monitor, and secure your integrations for you.


6 Key Business Benefits of using Alumio’s iPaas for Agencies & System Integrators

1) Let the API Datapoints be created via SAP Consultants

Risk of low quality & performance errors
If your team will create the data points in the API’s for a fully blown SAP B2B portal, for the first time, the risk of forgetting data fields, the wrong type / logic of creating webservices in a way they will not perform is enormous.    

Let's give you 1 example and insight:   In order to create a customer or so-called self-service portal in your B2B eCommerce, where customers can have a look to their current stats of orders and deliveries, or the history of orders, you need to create 2 separate webservice to make sure you are not over requesting the SAP API. You need to create a separate web service which only requests the header information (invoice number,  for only the latest 10 items, etc and 1 separate which request the detailed information of an invoice. rserd customer will look for a list of first and only will have a look to 1 order/ delivery. The API call of the headers is exceptionally light, and the request of detailed information is a bit heavier. By using 2 APIs call for this feature, you are preventing to request all the detailed information for every user, which will visit the self-service portal. This way if building the API’s is 98% lighter than requesting all detailed information for all orders by all users!

The risk of configuring your webservice in a way which will get a big load to your SAP is enormous. When requesting all products, B2B Prices, Orders or Invoices to your SAP using real-time calls via a wrong logic, it may cause serious  performance problems. It is  therefore extremely important to configure the webservice with the right logic, using a smart caching  mechanism, to not request data in real-time by using “call” requests to your  API webservices, however  use a push mechanism to prevent big load and performance issues

2) Use an off the shelf certified and proven SAP API Plugin

1) Let the API Datapoints be created via Dynamics Consultants

Risk of low quality & performance errors
If your team will create the data points in the API’s for a fully blown Dynamics B2B portal, for the first time, the risk of forgetting data fields, the wrong type / logic of creating webservices in a way they will not perform is enormous.    

Let's give you 1 example and insight:   In order to create a customer or so-called self-service portal in your B2B eCommerce, where customers can have a look to their current stats of orders and deliveries, or the history of orders, you need to create 2 separate webservice to make sure you are not over requesting the Dynamics API. You need to create a separate web service which only requests the header information (invoice number,  for only the latest 10 items, etc and 1 separate which request the detailed information of an invoice.The customer will look for a list of first and only will have a look to 1 delivery. The API call of the headers is exceptionally light, and the request of detailed information is a bit heavier. By using 2 APIs call for this feature, you are preventing to request all the detailed information for every user, which will visit the self-service portal. This way if building the API’s is 98% lighter than requesting all detailed information for all orders by all users!

The risk of configuring your webservice in a way which will get a big load to your Dynamics is enormous. When requesting all products, B2B Prices, Orders or Invoices to your Dynamics using real-time calls via a wrong logic, it may cause serious  performance problems. It is  therefore extremely important to configure the webservice with the right logic, using a smart caching  mechanism, to not request data in real-time by using “call” requests to your  API webservices, however  use a push mechanism to prevent big load and performance issues

2) Use an off the shelf certified and proven SAP API Plugin

Learn More
No items found.
More Digital Trends
iPaaS Value

Alumio Deep Dive: A Basic Transformer

A transformer is a reusable building block, and the parts that make up a transformer are reusable and precreated for Alumio users.
Alumio Deep Dive: A Basic Transformer

Data sent from one application to another needs to be made compatible to be accepted. The exchange protocol and file types can be different (SOAP, REST), but so can the specific required information (ex. filter out unneeded information or add a new required field), the way values are described (ex. "red"/"blue"/"green" versus "R"/"B"/"G" versus 0/1/2) and other similar - but critical - details.

Alumio calls this transforming data, and the building block for that a transformer. A transformer is a reusable building block, and the parts that make up a transformer are reusable and precreated for Alumio users. It is the most powerful and flexible part of Alumio that provides non-programmers a quick start to create a reliable solution to connect applications.

Orders example

Suppose you are using Alumio to transfer orders from your e-commerce website to a Warehouse Management System (WMS), so that products can be shipped and your customer is satisfied. What you may find, when you ask your online shop for the latest orders, that it gives a list of orders paid as well as those not yet paid. Surely, the customer should pay before receiving items!

A simplified list of orders, provided by the e-commerce website:

Magement-Data-from-Online-Shop.png

When the state is "processing", then it should be provided to the WMS, otherwise it should be skipped until it is paid.

Alumio can apply a transformer to this list. Such a transformer can look like this:

Figure: transformer with explanation
Figure: transformer with explanation

Alumio contains a transformer tester to see how it behaves when provided with actual data:

Magement-Transformer-Tester.png

In the image above you can see how the second item of the list was removed and the other two items were kept. It works as expected and can be implemented in a Alumio installation of the client needing this solution.

In a follow-up post we will discuss the different kinds of transformers available in Alumio. Already shown here is filtering. Others kinds are: changing data, mapping data from one set onto another, moving nodes, copying nodes, transforming on conditions, and chaining multiple transformations together. Make sure to subscribe so you don't miss it!

Connect your eCommerce platform to your ERP

Ready to dive in?

Get your demo today.

Let's build an IT-landscape for tomorrow, together!