This article covers how to use the Local Atom Migration process that is within the Boomi process library. As a company learns of new requirements, it can make sense for them to move from one local atom to another or from a Boomi Cloud Atom to a local atom.

A quick overview of the steps that are involved within programmatically migrating your Local Atom.

1. Before you execute the process, you will need to install a new atom (or molecule, but will say atom throughout the article) to the same environment as the original atom. You will need to get the source atom and destination atom id.
2. Update all encrypted fields within the environment extensions. These values are stored locally on the source atom and need to be re-applied.
3. Execute the process to sync the following.
4. Sync the Process Schedules.
5. Sync the Process Status and turn all of the processes off on the original Atom.
6. Sync the Listener Status. The listeners will remain active on the original Atom.
7. Sync the Process Properties (i.e. persisted dynamic process properties, last successful run date).
8. Sync the Atom Counters.

Once the process has been executed, if there are any errors, all changes will be rolled back and the list of errors can be found at the Return Document shape in Process Reporting. If the process is successful, then the next steps would be to:

1. Migrate the new URLs, user names, and passwords to any endpoints connecting to the new Local Atom’s shared web server.
2. Ensure the new Local Atom is functioning as expected.
3. Delete the original Atom. The original Local Atom will have ‘-DEPRECIATED’ appended to the name.

The process does not migrate all settings and information.

• Atom Queues: Since queues are generally short-lived, the queues should finish executing but no new data will be added unless they are used to decouple listeners, which remain active on the original Atom.
• Share Web Server Settings: The AtomSphere API for shared web server settings only migrated a limited amount of information for Atoms. User names and passwords for basic authentication will be to be recreated since they can not be moved. The process does not turn off the listeners on the source atom and that will allow you time to transition each endpoint that is sending to each web server service.
• Environment Extensions Passwords: All environment extensions will be transferred to the new Atom except for any fields that are encrypted. These will need to be repopulated before the process is executed.

Getting Started

Preparing your Boomi Account for the Atom Migration

The new Local Atom will temporarily increase your account’s license count. Please contact Boomi Support or your Boomi Account Representative if you are unsure of the effect of the new Local Atom will be on your Boomi account. This change should only be temporary because once you have confirmed that the migration was successful, the original Atom can be deleted and your license count will return to the original count.

Atom Id

The process will require your source Atom Id and destination Atom Id. The Atom Id can be easily located by going into Atom Management -> click the source Atom -> Atom Information -> Atom Id. This needs to be done on both atoms.

Figure 1. Locate Atom Id.Once you have this information, you will need to populate the Local Atom Migration process property within the folder.

Figure 2. Local Atom Migration Process Property.

Figure 3. Populate Local Atom Migration Process Property.

The two fields need to be populated with the information obtained above (Source Atom Id and Destination Atom Id). This data will be populated within the message shape that is at the beginning of the process.

Connector Setup

The processes uses a HTTP Connector to connect to Boomi AtomSphere API because a few of the endpoints are not available through the SOAP based AtomSphere API connector. The connector is labeled Atomsphere API.

Figure 4. Atomsphere API HTTP Connector.

AtomSphere API credentials can be obtained by clicking Settings at the top -> User Information -> AtomSphere API Tokens -> New. The token is associated with the user who is creating it and they must also have privileges for AtomSphere API. Boomi recommends that the user be assigned the Boomi Admin role to ensure that the user is able to do everything that is involved with this migration. Boomi also recommends using tokens over the user’s password, since the tokens can be easily revoked if needed.

Figure 5. AtomSphere API Token Creation.

Next, populate the AtomSphere API HTTP Connector with the token that was just created. The user name will be BOOMI_TOKEN. and the password will be the token that was just created.

Figure 6. HTTP Client Basic Auth Credentials.

Once those are complete, the process can be deployed to any Atom (even the one being migrated) within your account and manually executed. The process takes a few minutes to execute depending on the volume of processes on the Atom. Once the process is complete, check the process reporting to confirm that the process executed successfully. The listeners will still be active on the original Atom. This will provide time for the endpoints using the web services server to be migrated to the new Atom. Once, the new Atom has been confirmed that it is working as expected, the original Atom, which contains DEPRECIATED at the end of the name, can be deleted under Atom Information.

Figure 7. Delete the original Atom.

Article originally posted at Boomi Community.