Note that using this template is subject to the conditions of this License Agreement. Please review the terms of the license before downloading and using this template. In short, you are allowed to use the template for free with Mule ESB Enterprise Edition, CloudHub, or as a trial in Anypoint Studio.
I want to migrate accounts from one database to another.
This Template should serve as a foundation for the process of migrating accounts from Database A to Database B, being able to specify filtering criteria and desired behavior when an account already exists in the Database B.
As implemented, this Template leverage the Batch Module. The batch job is divided in Input, Process and On Complete stages. During the Input stage the Template will select all the existing Accounts that match the filtering criteria from Database A. The last step of the Process stage will create / update the accounts in Database B. In addition, it will assign Account Representatives by the zip code of the source Account. Finally during the On Complete stage the Template will both output statistics data into the console and send a notification email with the results of the batch execution.
Note: This particular Anypoint Template illustrate the migration use case between two Databases, thus it requires a Database instances to work. The Anypoint Template comes packaged with a SQL script to create the DB table that it uses. It is the user responsibility to use the scripts to create the tables in an available schema and change the configuration accordingly. The SQL script files can be found in src/main/resources/
This template is customized for MySQL. To use it with different SQL implementation, some changes are necessary:
- update SQL script dialect to desired one
- replace MySQL driver library (or add another) dependency to desired one in POM
- replace attribute
driverClassNameof suitabledb:generic-configelement with class name of desired JDBC driver in src/main/app/config.xml - update JDBC URL in
mule.*.propertiesfile
There may be a few things that you need to know regarding DB, in order for this template to work.
This Anypoint Template may be using date time/timestamp fields from the DB in order to do comparisons and take further actions. While the template handles the time zone by sending all such fields in a neutral time zone, it can not handle time offsets. We define as time offsets the time difference that may surface between date time/timestamp fields from different systems due to a differences in the system's internal clock. The user of this template should take this in consideration and take the actions needed to avoid the time offset.
There are no particular considerations for this Anypoint Template regarding DB as data origin.
There are no particular considerations for this Anypoint Template regarding DB as data destination.
Simple steps to get Database to Database Account Migration running. In any of the ways you would like to run this Template this is an example of the output you'll see after hitting the HTTP endpoint:
ID:6eea3cc6-7c96-11e3-9a65-55f9f3ae584e
Records to Be Processed: 9
Start execution on: Thu Nov 19 18:05:33 GMT-03:00 2015
In this section we detail the way you should run your Anypoint Template on your computer.
First thing to know if you are a newcomer to Mule is where to get the tools.
Mule Studio offers several ways to import a project into the workspace, for instance:
- Anypoint Studio generated Deployable Archive (.zip)
- Anypoint Studio Project from External Location
- Maven-based Mule Project from pom.xml
- Mule ESB Configuration XML from External Location
You can find a detailed description on how to do so in this Documentation Page.
Once you have imported you Anypoint Template into Anypoint Studio you need to follow these steps to run it:
- Locate the properties file
mule.dev.properties, in src/main/resources - Complete all the properties required as per the examples in the section Properties to be configured
- Once that is done, right click on you Anypoint Template project folder
- Hover you mouse over
"Run as" - Click on
"Mule Application"
Complete all properties in one of the property files, for example in [mule.prod.properties] (../master/src/main/resources/mule.prod.properties) and run your app with the corresponding environment variable to use it. To follow the example, this will be mule.env=prod.
After this, to trigger the use case you just need to hit the local HTTP Listener Connector on the port you configured in your file. If this is for instance, 9090 then you should hit: http://localhost:9090/migrateaccounts and this will run the migration process and send the batch process statistics to the email addresses configured.
While creating your application on CloudHub (Or you can do it later as a next step), you need to go to Deployment > Advanced to set all environment variables detailed in Properties to be configured as well as the mule.env.
Once your app is all set and started, supposing you choose db2dbaccountmigration as domain name to trigger the use case, you just need to hit http://db2dbaccountmigration.cloudhub.io/migrateaccounts and report will be sent to the emails configured.
Mule Studio provides you with really easy way to deploy your Template directly to CloudHub, for the specific steps to do so please check this link
In order to use this Mule Anypoint Template you need to configure properties (Credentials, configurations, etc.) either in properties file or in CloudHub as Environment Variables. Detail list with examples:
- http.port
9090 - page.size
200
- db.a.jdbcUrl
jdbc:mysql://localhost:3306/mule-a?user=mule&password=mule - db.b.jdbcUrl
jdbc:mysql://localhost:3306/mule-b?user=mule&password=mule
- smtp.host
smtp.gmail.com - smtp.port
587 - smtp.user
email%40example.com - smtp.password
password
- mail.from
batch.migrateaccounts.migration%40mulesoft.com - mail.to
[email protected] - mail.subject
Batch Job Finished Report
- zip2accountRep=
['90210' : 'Mark Anthony', '95060' : 'Daniel Craig', '95014' : 'Martin Jacobs', '04001' : 'Bill Elliot']
This section is not relevant for this use case.
This brief guide intends to give a high level idea of how this Anypoint Template is built and how you can change it according to your needs. As mule applications are based on XML files, this page will be organized by describing all the XML that conform the Anypoint Template. Of course more files will be found such as Test Classes and Mule Application Files, but to keep it simple we will focus on the XMLs.
Here is a list of the main XML files you'll find in this application:
Configuration for Connectors and Properties Place Holders are set in this file. Even you can change the configuration here, all parameters that can be modified here are in properties file, and this is the recommended place to do it so. Of course if you want to do core changes to the logic you will probably need to modify this file.
In the visual editor they can be found on the Global Element tab.
Functional aspect of the Template is implemented in this XML, directed by one flow responsible of excecuting the logic. This file contains a Batch Job which handles all the migration logic.
This is the file where you will fiund the inbound and outbound sides of your integration app. This Template has only an HTTP Listener Connector as the way to trigger the use case.
HTTP Listener Connector - Start Report Generation
${http.port}is set as a property to be defined either in a property file or in CloudHub environment variables.- The path configured by default is
migrateaccountsand you are free to change it for the one you prefer. - The host name for all endpoints in your CloudHub configuration should be defined as
localhost. CloudHub will then route requests from your application domain URL to the endpoint.
Flow triggerFlow executes a Batch Job defined in businessLogic.xml, which handles all the migration logic. This flow has Exception Strategy that basically consists of invoking the defaultChoiseExceptionStrategy defined in errorHandling.xml file.
This is the right place to handle how your integration will react depending on the different exceptions. This file holds a Choice Exception Strategy that is referenced by the main flow in the business logic.