Handling inconsistent Legacy Data & Newly Created data in Teamcenter

This blog is created as a response and solution to the above PLM challenge, This is a part of our weekly Wiser Wednesday Challenge on Linkedin – Aimed to add value to the PLM community.
Check out Quiz #2 on our LinkedIn page.

Handling Mandatory Attributes during Migration

The Easy Part

So, if we just focus on requirement #1 then the solution appears to be very straightforward. We need to make the Base Material attribute mandatory whenever a new Part is created in Teamcenter. 

Here you can use the Operation Descriptor in BMIDE to make this attribute "Required" and "Visible". 
This configuration will make sure that whenever a Part is "created", "revised" or "saved as", the user will have to provide a value for Base Material and cannot leave it blank.

I am happy we have successfully addressed the 1st part of the requirement. But does this also satisfy the 2nd part? A definite NO! Let us look at where the gap is.

"Required" is not required - handling the migrated data

Since we don't have Base Material values for all legacy parts, making the Base Material as Required will give an error while migrating the legacy data. Hence the Operation Descriptor solution will not work and we will have to look at some other options.

The one option that will handle both cases is as enlisted below.

1. Create a Pre Action on the IMAN_Save operation for the Part business object.

2. In the custom ITK code for this Pre Action, check whether the Part is being created from the UI or is created from the migration script.

3. If the part is created from the migration script skip the check for Base Material being NULL, whereas if the part is created from UI, restrict and throw the error that Base Material value cannot be empty.

How do we differentiate between Parts created from UI and Migration?

In the above customization approach, the obvious question that everyone will have is how to differentiate between Parts created from UI and Migration. Here is how you do it.

1. Define a custom preference say with the name "c1_skip_attribute_check_for_migration_users".

2. Use this preference to store the user ids of all the users who would be executing the migration scripts. Typically these migration users are system / DBA who will not be used for normal business activities.

3. In the Pre Action on IMAN_Save, check the session user who initiated the Part creation. Check if this session user id is already available in the list of user ids provided in the preference  "c1_skip_attribute_check_for_migration_users".

4. If the user id is available in the list of user ids provided in the preference, then we can clearly see that this Part is being created through migration scripts. On this basis, we can skip the check for mandatory attributes for migrated data.

Can we avoid customization?

With the customization coming in the game, it's always the least preferred option, given the fact that it increases maintenance overheads and also makes upgrades a costly affair. So, in this case, also it would be handy if we can avoid the Pre Action customization. 

And there is a way how we can do this. Run these below steps with the customer

1. Check the size of the Part data you are migrating.

2. Check if the customer can provide you with the corresponding Base Material for Parts which are having NULL values for Bas Material. Typically this data might be available in their ERP or other applications as the Parts have already been manufactured.

3. If the size of the data is not large enough and the customer is ready to provide Base Material information easily, then correct the Parts to be migrated in the staging database before feeding it into the migration script.

4. With this, you avoid the customization and all legacy parts are migrated with Base Material information - for newly created Parts the Operation Descriptor change will ensure that users provide Base Material information.

Can we add the icing on the cake here?

When we review solutions, there are always questions around scalability, completeness, and allied requirements, against the solution approach, is measured.

In this case, also we have the scope to make this solution more complete or more clinical. For that, we will have to provide a facility or process through which the legacy parts will get recycled and the Base Material information on them will be updated over time.

1. One of the process changes could be that whenever a BOM is released, provide a check either through a workflow or utility that validates all child parts being released have Base Material information populated. 

2. In cases where legacy parts are used as child parts, the workflow validation will highlight those parts with missing Base Material. These would typically be the legacy parts, which the users can update every time before releasing the BOM. 

3. In this way, you will also enforce users to correct the legacy parts every time they plan to use them.

This will help in getting the data corrected on a need basis and will also ensure that data consistency is maintained before the data is used anywhere.

Is this the only solution to the challenge?

Definitely Not! The solution presented here is just to provide a broad guideline on the factors/constraints to be considered while addressing such requirements. However this same problem may have 2 or 3 variations of this solution based on the business situation, impact on down-line applications or other related impacting requirements.

And hence we would be glad to hear your perspective on the solution approach demonstrated, your experience handling legacy data and anything to do with Teamcenter or PLM :) Please comment and let us know your thoughts!!

Blog by Digvijay Gavas.