I've never worked with this but i think this can be helpful.
AUTOMAP – FRIEND OR FOE
Before we explore the plug-in API, let’s examine the AutoMap feature to appreciate the reasons this plug-in is a valuable addition to the DI Studio feature suite. When building a job, developers will often start with a blank canvas. Developers will generally know the structure of the target table(s) they are attempting to load, but may have to make a number of transformations to the source tables to get the data into the desired target structure. These transformations may be trivial changes - such as sorting the data by a particular column, or appending rows from two tables with a shared structure and common column names into a single table. Often times, the transformations are more complex and require numerous interim changes to achieve the target table structure.
By default, AutoMap is turned on for new job nodes. This means that when a node is connected to the source and targets, DI Studio will query the SAS® Metadata Server to determine if it is possible to automatically build the column level mappings between the source and target tables. To build these mappings, DI Studio looks for columns that have the same name, type, and length. Columns meeting these criteria are automatically mapped to one another, saving the user time because these obvious mappings are taken care of behind the scenes. But the “behind the scenes” part is where things get interesting. Some features in DI Studio are triggered by the user, such as submitting a job or adding a new node. Other features, such as AutoMap, are triggered by system events. For example, assume a large job has been built and a number of changes have been made beyond the generic auto-created column mappings. Changes to source tables or job nodes early in the job flow will cause DI Studio to trigger AutoMap and cascade any changes throughout the job flow – all without user notification! This means that there is a strong possibility that the tool is going to destroy your work if you are not careful to turn off AutoMap for every node in the job. It is easy to see how in large jobs this can be particularly painful. Saving early and often is a best practice to avoid this issue, but a better solution is to work on the job to a point where you are comfortable that AutoMap is no longer adding any value and then turn off AutoMap for all nodes in the job, ensuring that DI Studio will not make any unwanted changes. At the SAS® Metadata Server level, jobs are represented as objects. These objects have properties representing various attributes (such as a collection of transformation activities representing each individual job node). At the individual job node level, there are metadata attributes that tell the system whether AutoMap is enabled or disabled for that specific node. By leveraging the DI Studio plug-in API, one can programmatically manipulate the metadata to put a job into a desired state. To disable AutoMap, one needs only trace through all the nodes stored in metadata and either set (or unset) particular properties on the job nodes to tell the SAS® Metadata Server that AutoMap is disabled for all nodes. Out of the box, this feature is surfaced by right-clicking on a node in the process editor at the job node level. But in a large job, turning off AutoMap manually on all job nodes is both time consuming and error prone. Missing a single node leaves the job in an undesirable state when there is a possibility that DI Studio triggers AutoMap and causes changes to be overwritten. Wouldn’t it be nice if you could click on a job and turn off AutoMap at the job level just as easily as you can delete or copy a job?