1.Get started

This tutorial will give you a clear explanation on how to use Myddleware.

In this process, we will be connecting two solutions SuiteCRM and Prestashop as we go along. You can also follow this tutorial by using another application that is already connected to Myddleware like Salesforce or Magento for eg…

To start, log in to Myddleware and create your connectors for these solutions.


What is a connector ?

A connector is the object which allows Myddleware to connect to the solution (SuiteCRM or Prestahop for example). This allows Myddleware to be able to read or to write into the solution.

Before we do anything, let’s first of all log in to Myddleware by entering your login and password :








Now, let’s create a connector to give Prestashop and SuiteCRM access to Myddleware. So click on “Connector”  then “Create” :


Then select SuiteCRM in the solution list, add the parameters, name your connector, test it and if the connection is OK then click on “Save the connector” :


Myddleware is now able and ready to read or to write into SuiteCRM.

In the same way, we will now create the connector for Prestashop :


Now that you have created your connectors, you can now set up your first rule to transfer your data.


In this chapter we will create the first rule. The goal is to send all Prestashop customers to SuiteCRM accounts.

3.1.First rule

This chapter deals with rule creation. The rule is the root of Myddleware. It aims at guiding Myddleware on what to do with the data and how it should be transferred.

3.1.1.Select data

To create your first rule, click on “Rule” then “Creation” :


Then follow these steps :

  1. Click on the source solution : it is the solution where Myddleware will read the data.
  2. Click on the target solution : it is the solution where Myddleware will write the data.
  3. Add a name to your rule.
  4. Select the connector you have created for the source solution.
  5. Select the connector you have created for the target solution.

Why is there a list of several connectors ?

Myddleware allows you to have several connectors for a solution in case you want to connect several instances of the same solution or if you want to have different connectors with different authorisations.

If all connectors are still valid, you will be able to select the module corresponding to the data you want to transfer :


We want to create an account in SuiteCRM for all customers in Prestashop. To do so, select the “e-shop customers” module for Prestashop and the “Accounts” module for SuiteCRM. Then click on “Go to the mapping of fields”.

3.1.2.Map your fields

The fields mapping allows you to indicate which data from your source application you want to transfer. Let’s start by mapping the “email” field using a drag and drop system :


As you can see, Myddleware enables a simple mapping of fields with a unique drag and drop. You can do the same by transferring the “note” field into the “Description” field, and the “Website” field into the target “Website” field.

Now we will fix a value for the “account_type” field. We want all accounts created by Myddleware via this rule to have the type “Customer”. To do that, click on “Create a formula” in the “account_type” field :


Myddleware opens a pop-up to create your formula. You can use the “Target” dropdown list corresponding to all the dropdown lists in the target module. Select the “Customer” value in the section “Account type” of this list. Then click on the button formula_arrow to copy the right text in the formula area :


Finally click on “Confirm” to validate your formula :


We now want to send the first name and the last name from Prestashop to the account name of SuiteCRM. But there are 2 fields in Prestashop and only one in SuiteCRM. So we have to create another formula.

First, drag the fields “firstname” and “lastname” and drop them into the “name” field. You should have the account field looking like this :


Then click on “Create a formula” in the field “name”.


Double click on a field to insert it in your fomula. So double click on “firstname” and “lastname”. But we want to add a space between the first name and the last name. To do that we use the “.” to concatenate some text. Your formula has to be this one: {firstname}." ".{lastname}

Finally click on “Confirm” to validate your formula :


The mapping of fields is finished. You can now test it to control your rule. Click on “Simulation” and “Test data”. Myddleware will get the last data in Prestashop and transform it with your own rule. Obviously, the test will only work if you have at least one data in your source application.


We will talk about the tabs “Relationships” and “Filters” in another chapter.

3.1.3.Confirm the rule

To finish the creation of this rule, click on “Confirmation” :


You will then see 2 parameters :

  1. Synchronization type : Depending on the solution, you could have the choice to read newly created data or all data, created or modified in the source module. In our example, if you only want to send new customers created in Prestashop to SuiteCRM, then select “Create data only”. Otherwise, if you only want to send customers’ modifications in Prestashop to SuiteCRM, then select “Create and update data”. In our example we selected “Create and update data”. This process is based on the reference date that you can set up.
  2. Avoid duplicates fields : You can select one of these fields if you want Myddleware to check if a record with the same value already exists in the target solution. If so, Myddleware will only update this data and won’t create a duplicate. But to be able to duplicate a field, the field must be present in the fields mapping. In our example, we selected “Email”.

Finally, you can click on “Confirm” to create the rule. After which, the page with the detail of your rule should appear.


3.1.4.Rule detail

When you open a rule, all its details appear :


You will see an On/Off switch enabling “automatic synchronisation”. If this option is on, the job which synchronises data in background task will run this rule. If it is off, the background job will not run this rule. See the install guide if you want more information about this switch as well as how to set up the background task.

You will see these buttons :

  • Run the rule : It allows you to run the rule manually even if the switch “Enabling the automatic synchronisation” is off.
  • Edit the rule: It allows you to edit the rule.
  • Display the transfers : It allows you to see all the data transfers generated by the rule.
  • Delete the rule : It allows you to delete the rule.

You can also see all the tabs if you want to display the fields mapping, the relationships, the filters or the parameters.

We will explain what these parameters are in the next chapter.


When you open a rule, click on the tab parameters :


You will see 2 parameters on the left :

  • The reference date : This is the date Myddleware uses for data reading in source applications. For example, if you set today’s date, only today’s created or modified data will be sent to your target application. (This also depends on the mode of your rule : the “Create and update data” rule mode concerns modified data while the “Create data only” rule mode concerns created data). If you want to migrate your data, all you need to do is put this date in the past. Then all created/modified data after this date will be read by Myddleware.
  • Deleting data : You can ask the system to delete the transferred data of your rule after x days. To use this functionality you have to set the background task “clear data”. See the install guide. For your information, this job will delete all the data you have transferred for this rule, except the ids which are necessary for the correct functioning of Myddleware.

On the left, there is an option to simulate the amount of data you want Myddleware to read depending on the reference date. You can change the reference date if you need to then click on “Save” to obtain a simulation of the number of transfers.

3.1.6.Run the rule

Your rule is now ready. If you didn’t change the reference date, you can create a new record in your source application.

Then return to your rule and click on “Run the rule” :


When Myddleware returns to the rule, an information message page appears. This is a link to redirect you to the task that Myddleware is running. To open, click on the link.


In our example there is only one transfer, but you can send several data transfers in one task.

The transfers can then be opened by clicking on “Display the transfers” :


All transfers for this rule will become visible to you :


You can then click on each one of the transfers to open:


You will then be able to see what Myddleware has read in the source application and what has been sent into the target application.

Your rule is at this stage up and running now. Let’s now create another rule to link it to the one you’ve already created.

3.2.1.Select data

To create a rule allowing two rules to relate with one another, both rules have to have the same connector. Let us  now create a new rule with the same applications and connectors by selecting the following modules “The customers orders” in Prestashop and “Opportunities” in SuiteCRM (use the “select modules” button)


Then click on “Go to the fields mapping”.

3.2.2.Map your fields

You can now map your fields like this :


When we transfer a date, we often have to change the format because the solutions don’t have the same format. In this case, we want to transform the order date_add (format datetime) into the opportunity closed date (format date). We then create the formula :
changeFormatDate( {date_add}, "Y-m-d H:i:s", "Y-m-d" )
Now insert the field “valid” into one SuiteCRM field. We will need it in case we want to filter.

Now let’s set up our first relationship.

3.2.3.Create relationship

We can create relationships in Myddleware that not only allow us to transfer unrelated data items but whole data models entirely.

To send an order in SuiteCRM, we have to link it to the related account. In order to do so, we need to retrieve the account id corresponding to the customer linked to the order in Prestashop.

To do that, we will link this new rule to the previous rule where we will be able to find the SuiteCRM account id.


In other words, we get the SuiteCRM “Account ID” from the rule “Customer” by using the customer_id in the Prestashop order.

3.2.4.Filter your data

You can also decide to filter the data you want to send into your target application. To do so, click on the “Filters” tab :


In our case, we only want to keep the orders having the field “valid” equal to 1. Only these orders will be sent to SuiteCRM

You can then save your rule.

3.2.5.Run the rule

Now run your rule by clicking on “Run the rule” :


Open a transfer and you will see that Myddleware retrieved the “account id” from the “customer id” on the Prestashop order using the rule “Customer” previously created.


In SuiteCRM, the opportunity is now linked to the account.


The transfer is the record which stores the data read in the source application, transformed by Myddleware and sent to the target application.

4.1.Search transfers

If you click on “Transfer => List”, you will be able to search tranfers. For example, you can search by rule and status :


You can search by creation/modification date, global status and ID too. You can use the character “%” in the search. For example,  if we search “%4d60%”, we will find all the ids which contain the string “4d60” :


Now open a transfer and follow the detailed explanation on the transfer.

4.2.Transfer detail

There are 3 distinct parts in a transfer :



  1. The header data :
    • Rule name and version related to this transfer
    • Status related to the global status (see below):
      • New (Open) : When the transfer is created.
      • Create_KO (Cancel) : When the transfer creation failed.
      • Filter (Cancel) : When the transfer is filtered because of the rule filter.
      • Filter_OK (Open) : When the transfer is not filtered.
      • Filter_KO (Error) : When Myddleware failed to check if the transfer has to be filtered.
      • Predecessor_OK (Open) : When all transfers with the same source ID are closed.
      • Predecessor_KO (Error) : When at least 1 transfer with the same source ID isn’t closed. Myddleware will wait until the other transfer have been successfully sent before sending this transfer. In our example, we can’t update the status of an order if this order hasn’t been created in the target application.
      • Relate_OK (Open) : When no other transfer related to this transfer (in another related rule) isn’t closed.
      • Relate_KO (Error) : When at least 1 transfer related to this transfer (in another related rule) isn’t closed. In our example, we can’t send an order if the customer hasn’t been sent.
      • Transformed (Open) : When the transfer is successfully transformed.
      • Error_transformed (Error) : When Myddleware failed to transform the transfer.
      • Ready_to_send (Open) : When the transfer is ready to be sent to the target application.
      • Error_history (Error) : When Myddleware failed to get the data from the target application, only when the transfer updates data.
      • Send (Close) : When the transfer is successfully sent.
      • Error_sending (Error) : When Myddleware failed to send the data to the target application.
      • No_send (Cancel) : When there is no identification between the data in the target application and the data Myddleware should sent. In this case, Myddleware cancels the transfer.
      • Cancel (Cancel) : When the transfer is manually cancelled.
    • Mode indicates the mode of the rule related to the transfer:
      • 0 : The rule will create and update data to the target application.
      • C : The rule will only create data to the target application.
      • S : The rule will search for data in the target application (no creation and no modification).
    • Type of the transfer :
      • C : The transfer creates data into the target app.
      • U : The transfer updates data into the target app.
    • Global status
      • Open : The transfer is still in process.
      • Cancel : The transfer has been cancelled.
      • Error : The transfer is locked and has an error.
      • Close : The transfer has been successfully sent.
  2. The detail of the data in 3 parts
    • Source : Data read in the source application
    • Target : Data sent to the target application
    • History : If the transfer updates data in the target application, we get the data from the target application before we modify it.
  3. The logs with the transfer with its historic status


4.3.Manage a transfer in error

When a transfer is in error, you can modify it, by resending it or cancelling it. To be able to modify the data, double click on target data, change the data and click on the validation icon :


Then try sending the data again to the target application by clicking on “Reload the transfer” or cancel it by clicking on “Cancel the transfer”.


4.4.Mass action

You can reload or cancel several transfers at the same time in the transfer list view.

Note: Only transfers in error can be reloaded or cancelled.

Select the transfer you want to reload or cancel and click on “Cancel transfers” or “Reload transfers” :


We will discuss how to manage tasks in the next chapter:


A task is an execution of the program which reads data, manages all ûnclosed or cancelled transfers from the source application, and then sends them to the target application. This allows for many transfers to be carried out in one task.

To list the tasks, click on “Task” then on “List” :


Then open a task by clicking on its Id to see the details of what happened during the execution of the task :


If the task is still running (status Start), there will be option to click on 2 buttons :

  • Refresh : To refresh the page and see how the task is executing and when it is finished.
  • Stop task : To stop the task.


In the example above, we showed you how to create a relationship while keeping the same data model. Customers and orders from Prestashop were sent to the Accounts and opportunities modules in SuiteCRM.

In the examples, below you will learn how to create relationships with different data models :

  • One to many : The data from Prestahop in the module Customer will be sent to SuiteCRM in Account and Contact modules.
  • Many to one : The data from Prestashop in customer and address modules will be sent to SuiteCRM in the module Accounts.

6.1.1.One to many relationships

Now let us create 2 rules with 1 module in the source application to be sent to 2 modules in SuiteCRM. We have already created the rule which sends Prestashop customers to SuiteCRM accounts. Now we will re-use the same Prestashop module Customers and send the data to SuiteCRM’s contacts module.

Let’s create this rule :


Go to the fields mapping tab and map a few fields like firstname, lastname, birthday or email.

Then open the tab “Relationship”. We want to link the contacts to their accounts, which have already been sent to SuiteCRM in a previous rule. In this scenario, Myddleware would have to retrieve the SuiteCRM account IDs from the previous rule and send them into the contacts in order to link these contacts and the accounts that have already been created :


Now save the rule and run it. Don’t forget to put the reference date in the past if you want to retrieve data which already exists in Prestashop.

Now open a transfer. You will find that Myddleware has linked the right account to the matching contact.


The id “1” is used twice in the source data : the first time for the contact and the second time for the account. At this point, you have just created your first one to many relationship, ie one customer to 2 records (contact and account).

6.1.2.Many to one relationships

Here we want to create 2 rules with 2 modules in the source application to be sent to 1 module in SuiteCRM. We have already created the rule which sends Prestashop customers to SuiteCRM accounts. Now we want to send Prestashop customer addresses to SuiteCRM accounts.

Let’s create this rule :


Go to the fields mapping tab and map a few fields such as address1, address2, city, postcode…

Then open the “Relationship” tab. We want to send the adresses to the accounts that have already been sent to SuiteCRM in a previous rule. Just like the one to many relationship scenario, Myddleware will have to spot the SuiteCRM account IDs in the previous rule then update this account :


Here, we use the Account ID ie the ID of the target module in the current rule. This means that this rule will only update data.

Now save the rule and run it. Don’t forget to put the reference date in the past if you want to retrieve already exiting data in Prestashop.

Now open a transfer and you will see that Myddleware has found the right account to update :


The transfers and the accounts are now updated as expected.

6.2.Bidirectional rule

In our example, we have only shown you how to send data from Prestashop to SuiteCRM. But in reality, Myddleware allows you to send data in both directions, from Prestashop to SuiteCRM and from SuiteCRM to Prestashop.

One of the rules we have created is sending Prestashop Customers to SuiteCRM contacts. In this case, only modifications in Prestashop will be sent to SuiteCRM. But if the contact is modified in SuiteCRM, the modification won’t be sent to Prestashop.

So let’s create a new rule to send the modification of the SuiteCRM contacts to Prestashop. Select the same modules and connectors you used in your previous rule but in the opposite direction :


Go to fields mapping and map at least the fields firstname, lastname and email. Make sure you don’t use a field that will be updated everytime like the modification of the date of the record, you could create an infinite loop.

Go to validation. A new field will be displayed ie “Bidirectional synchronization” in addition to the opposite rule. Select the opposite rule and click on “Confirm” :


The opposite rule is displayed on the rule’s detailed view :


Activate both rules. Now, to test your bidirectional rule, modify a customer in Prestashop, go to the the rules list view and click on “Execute all active rules” :


Now open the task and you will see the contact that has been sent to SuiteCRM.


Notice that in SuiteCRM, the contact’s name was “Doe test” and but the name that was sent is “Doe”.  The name is now modified in SuiteCRM. Return to the rules list view and click again on “Execute all active rules”. Another transfer is sent as a result of Myddleware reading in SuiteCRM and detecting the modification we’ve just made. The transfer will automatically be cancelled to avoid an infinite loop :


The reason for this being that the data is already updated in Prestashop (which is normal since Prestashop is the source solution from which the data is being sent). So Myddleware detects that there are no modifications to send to Prestashop and thus cancels the transfer and stops what could result in an infinite loop.

Now you have to do this test in the opposite direction. To do so, modify the contact in SuiteCRM and return to the rule list view. Click once again on “Execute all active rules”. You only need to run the rules once, not twice as we did in the previous case. In fact, it depends on which rule has been activated first when you click on “Execute all active rules”. In one direction, you have to click on “run all rules” twice, in the other direction, once is enough.

At this point, your modification in SuiteCRM should be visible in Prestashop :


Once Myddleware detects the modification in Prestashop, it will try to send it to SuiteCRM. But once again, the transfer will be cancelled to avoid an infinite loop :


If the transfer isn’t cancelled, your server will continue to update the same contacts every time. To avoid this, you will have to detect why the transfer isn’t cancelled. It could be because you used the modification date, or because the data format is not the same in both applications. To solve this problem, remove some fields in your rule or create a formula to have the same data format in both applications.

Suggest Edit