Tips and Tricks - Component Management

Document created by mike_c_frazier Employee on Jan 3, 2013
Version 1Show Document
  • View in full screen mode
Component Management

Component management is an important concept to consider while using AtomSphere.  It is important to establish guidelines with your team so you can be respond to issues in the future like change management, version updates, and reusing components.

Topic Focus:
  •           Organization           
    •                     Folder Structure
  •           Naming Conventions
  •           Copy

The biggest takeaway from this article is to recognize the need for component management, decide on a strategy, communicate it with your team, and enforce.


Organization of components is essential to a successful deployment and management of AtomSphere. AtomSphere provides clients with the ability to reuse components across multiple processes such as map functions, sub processes, and intermediate profiles. You want to look for ways to factor these components into common folders when used in more than one process. Component management can also help with removing duplicate connectors, which can save you money.

Folder Structure

Determining the folder structure of your AtomSphere account is a key development step. One of the most commonly used structures involves creating a common components folder. This structure helps the user to draw commonly used components, like map functions, without needing to identify its location every time its needed or create a new copy. This is a great way to expedite your development cycle.
But what about just using multiple folders? This will depend on how you think about your integration scenarios. Do you want to create a folder per end application? What about a folder per business function? They key is to identify your unique solution and communicate that with others using your account.

Tech tip: for those familiar with coding, it can sometimes help to view folders as “packages” from an organization perspective. Common components that are referenced in multiple places should be “factored out” and moved to a higher-level or common folder.

Organization considerations–
  •           If it’s a small project, create connections folder under the root folder.
  •           Consider folders as units of work that you can copy.
  •           Avoid deeply nested folders and try to keep folder names concise.
  •           Compile common components at the highest possible factor.

Naming Conventions

Naming Conventions in AtomSphere are also important to component management. Depending on the size of your team, setting standards can help with future developments. Below are examples for some commonly used components in AtomSphere. Always try to be as short as possible to what the component is doing, but don’t add names that relate to specific future steps.

Example: Salesforce Connector
  •           Connection: Salesforce: Salesforce Developer Account Connection
  •           Operation: Salesforce Operation: Account Query by Type/Date

Example: Database connector to SQL Server
  •           Map Component: Map: Database to SQL Map

Example: Map function for CUSTOMER_ID to create data
  •           Custom Map Function: Map Function: CUSTOMER_ID Create

Example: Database Connector
  •           Connection: Database: Master DB (MySQL)
  •           Operation: Database Operation: Query Customer by  Date


As any programmer would agree, the ability to reuse old work is invaluable. As discussed before, AtomSphere offers  a way to reuse any component created in any process. We also include a copy tool that allows the developer to take a component previously created and create a new copy of that component in a predetermined file destination.  The copy feature allows a user to copy any component or complete process, both to another account they have access rights to or inside their own environment.

When copying a process to another account, AtomSphere will require you to copy all of the dependent components as well. Remember, without the dependents, the process would not run in another account. This feature is popular among AtomSphere partners. They can push skeleton versions of a process into a customers account, and then adjust the components to fit the clients needs.

The other type of copying available in AtomSphere is the ability to copy locally. This allows users to move processes and components into different folders in the component explorer without the need to recreate. It is very important to consider what you are copying, and if the situation dictates copying dependents. Below are some key considerations when copying.

Determine what you need to copy...
  •           -Is this a process or component?

If its a component...
  •           -Remember to rename the component once copied if you want to maintain two separate versions.

If its a process...
  •           -Do I need to copy all of the components that are already created (map functions, profiles, etc)

If you don’t copy dependents
  •           -Remember to rename the new process

If you do copy the dependents...
  •           -Remember to rename components accordingly
  •           -Determine if you should archive the original components

Things to remember:
  •           Copying connectors can lead to accidentally using multiple licenses for the same connection
  •           Copying with dependents will double the amount of components you have to maintain without changing their names.
  •           The revision history of a process does not copy when used in AtomSphere.
5 people found this helpful