As PLM services and solutions provider, we often get asked as to how we get ideas to develop new solutions. Frequently, we end up developing new solutions based on a particular situation while working on a project. Recently, we’ve been involved in Aras data migration project. The scope of the migration involved loading multiple revisions of objects with associated files, parent-child relationships, and references to other Items in Aras, like the Users and Identities. For this project, we configured the Aras Bulk Loader tool that is provided to Aras subscriber customers.

The Aras Bulk Loader Tool is a tool that allows you to map data from a ‘text’ or some type of delimited file to fields in Aras for a specified Item Type. So basically, you pick the Item Type you want to load data, associated a delimited file to it, and then map the columns from the delimited file to fields in Aras. The mapping of the columns to fields generates and xml (aml) file that controls the behavior of the data load. However, because I was dealing with multiple revisions and relationships I had to expand the configuration of the tool in the following ways to handle the following conditions:

Handling multiple revisions – When conducting an import the default initial xml (aml) line is as follows: <Item type=’Document’ action=’add’>. I had to change mine to: <Item type=”Document” action=”merge” where=”item_number=’@9′” serverEvents=”0″>

The key part of this is changing the action to merge and then having a where statement to the item_number (or document number), in my case. By doing this change it allows to first check if an item_number with the same name exists in Aras. If so it will add as a new Item. If not it will do a version for subsequent data imports that has a matching item_number. Since my data was organized by a revision in incremental order, these settings allowed to load multiple revisions of data.

Ignoring Methods – If you also look at the changed initial line above, you will see the following value as well – serverEvents=”0″. In my case, there were additional server methods added to the add events in Aras that dealt with new data. Since we did not use these methods called on the legacy data being loaded, we set serverEvents=”0″ to not call any of the server events. Though you need to be careful as there are some default out of the box server events. You need to make sure that you do not need any of the out of the box events being called when loading the data if you make this change.

Dealing with Relations (Links) – To load links I had to break the data load into two parts, the first part is where I loaded the flat Items as described above and the second part is where I loaded the relations. To do this my xml control file looked like the following:

<source_id>

<keyed_name>@2</keyed_name >

</Item>

</source_id>

<related_id>

< keyed_name>@5</keyed_name>

</Item>

</related_id>

</Item>

In this case, the Item Type being specified represents the relation – “Document Document”. I then need to load the Source ID (Parent) and Related ID (Child) values. Though to get them I had additional xml (AML) that searched for the previously loaded values and retrieved their IDs too so a relationship can be added to them. This is done via the aml referenced under the <source_id> and <related_id> nodes.

Setting the State – To set the state, I do not believe there is a way to do it through the Aras Bulk loading tool. In this case I had to execute the following SQL statement to set the state: UPDATE Document SET state = ‘Released’, current_state = ‘CC42636428304B579A1CDDC932187C27’, is_released = 1, permission_id = ‘8E51144B82D144D79EF7AD45EE31A16C’ where …

Though keep in mind that if you use the sql above you would need to modify according to your specific situation. In this case, the following values would need to be set:

State – i.e.the name of the state
Current_state – the ID of the specific State Item
Permission_id – the ID of the permission Item specific to the state
Is_released – 1 or 0 if the Item is in a ‘Release’ state
Where Clause – Make sure you have a proper where clause to only update the records you loaded and the state should be changed on.

The project is yet to be completed but the data is looking good in Aras based on testing so far. I also want to note, that the blogs in specific to using the Aras Bulk Loader tool. There was also a lot of work done to properly format and clean the data from the legacy system before it could be processed by the Aras Bulk Loader tool. However, how to best clean and prep the data can be left for another blog.

Please send me your feedback at info@xlmsolutions.com or myoung@xlmsolutions.com.

Thank you,

Marc Young.

Aras Data Loading Tool

Address