How To Migrate Processes to a New Atom

Document created by rich_patterson Employee on Jul 10, 2014Last modified by thanh_n88 on Aug 16, 2018
Version 5Show Document
  • View in full screen mode

Below is a high level, basic outline for migrating processes from one atom/molecule to another. The following instructions assume that you have environments with extensions enabled on your account. If not, work with a support team member to discuss alternative steps if necessary. 



During the migration, you will be attaching your processes to both the old and new atom, so you'll need double the licenses you're currently using. If you do not have enough licenses, please contact the Dell Boomi Support team and your account manager. Discuss with the support team member and the account manager how long you need to complete the migration and they will be able to provide temporary licenses to use during the migration. 


Configure new atom or molecule

If your old atom/molecule has any specific settings already set, do the same for your new atom/molecule. A couple of configurations to consider:

  • You may need to import Java certificates into the new JRE keystore
  • You may need to install Unlimited Strength Cryptography files
  • You should check the, atom.vmoptions, and other molecule related settings files like the procrunner, procworker, etc and apply the settings in there to the new atom/molecule accordingly
  • You should check the Shared Web Server settings from Atom management and make necessary changes
    Note: If it is a new atom on the same server, you must use a different port within Shared Web Server settings


Custom jar files

If any of your processes use custom scripts or drivers (.jar files), the contents of the userlib folder must be migrated to the new atom. You can either move them directly over or manage them via the custom libraries component. The deployed custom library will automatically take effect and add the jar files in it to your new atom when you attach the atom to the environment. 


Note: If you are changing OS or architecture, you may require different jar files or drivers to meet the new system's requirements


Attach the new atom to the existing environment

After you have checked the above, you are ready to attach your new atom to the environment. 



You will need to enter in your passwords for the environment extensions again. The passwords in extensions will not be applied automatically to your new atom. If you have a lot of passwords though, you can do the following to move passwords from one atom to another:


  1. Go to <<atom_installation_directory>>\settings\atom on the old atom
  2. Find the component ID of the connectors you are using
  3. Copy the folder(s) with the same component ID you found in step 2
  4. Paste them into the same location (<<atom_installation_directory>>\settings\atom) in the new atom
  5. Restart the new atom


Migrating schedules

The processes deployed on the environment should show up in your deployed processes tab on the new atom but without any schedules. To set the schedules you can either set them up again if it's just a few processes or you can use the Atomsphere API.


Here's a sample of the process you can use to move schedules over:


  1. Use the Query operation on the Process Schedule object to pull the current schedule for the old atom. The filter should be using the old atom ID
  2. Map the query response profile straight across to the update request profile since they all use the same field. You will add a default value for the atomID since it will be the new atom ID now
  3. Use the Update operation to pass the schedule to the new atom
  4. Confirm schedules have been copied to new atom. The schedules will be advanced instead of the Minute, Hour, or Day type you might have used before since the API translate the schedules as advanced automatically. The schedules should still be equivalent


Deployment history

Because you are attaching to the same environment, your deployment history will be carried over automatically.


Process properties, EDI sequence #s, CDC data

You may choose to migrate all processes at once or one at a time to allow for testing/validation on the new atom. For each (non-listener) process you wish to move:


  1. Stop the schedule(s) for the process on old atom
  2. Move persisted process properties like the "Last Successful Run Date"
    1. Go to ./execution directory on the old atom
    2. Find out the component ID of your process (you can look in the process URL or revision history window in the build tab)
    3. There should be a file in the executions folder named with the <<component_id>>.properties, copy it from old atom
    4. Paste it into the ./execution directory of the new atom
  3. Move counters/EDI Sequence #s/etc
    1. Go to the ./counter directory
    2. Similar to step 2, copy the ./counters/<<component_id>> folder from the old atom to the new
  4. Move the Find Changes file
    1. Go to the ./work/cdc directory
    2. Similar to step 2, copy the ./work/cdc/<<component_id>> folder from the old atom to the new
  5. Start the schedule(s) for the process on new atom
  6. Repeat as needed for each process


Listener processes (HTTP Server, AS2 listener, etc)

For listener processes, you may test the new listeners by using the port defined on the new atom's in Shared Web Server settings. A couple of considerations:

  • If you are directing client requests to your service via a router configuration, you may simply be able to re-route those requests to the new server/port
  • If you are using an external load balancer, you may be able to redirect the requests using the balancer
  • You may also choose to have your clients update their connection points to connect to your new servers
  • You may choose to detach (or stop) all the listener processes from the environment, then change the web server settings on the new atom to the port number of the old atom (if it's on the same server) and start the listener again


Execution history

Execution history will stay with the old atom. If information is required for past executions, you can look in process reporting or query the execution records object using the old atom name/ID. 


Removing the old atom

Once the migration is complete and all processes and listeners are now running on the new atom you can detach the old atom from the environment. Your account owner will remove the temporary licenses from your account. You can uninstall the old atom if you do not need anything else from it. 

7 people found this helpful