Leveraging the Debugging Capabilities

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 #5 on our Linkedin page.

Leveraging the Debugging Capabilities

Conditions in BMIDE

In Teamcenter BMIDE, conditions are used to control the applicability of business rules like Naming Rules, GRM Rules, workflow visibility, LOVs etc. They can be defined using object types, properties, groups, roles or relationship objects.

Several types of conditions can be configured using BMIDE, including:

Action conditions: These trigger specific actions or events based on changes to data or the state of an object. i.e., Extension attachment based on certain conditions.

Validation conditions: These enforce business rules and data validation on specific data items or object types. i.e., if the condition is satisfied show the applicable workflows.

Conditions can also be nested and combined to create complex conditions. For example, a condition can be set to show a particular Naming rule to a specific group, role, or object.

In summary, BMIDE conditions give granular control over configuring business processes, and control behaviour by enforcing the business rules.

When we use conditions defined in BMIDE and when the conditions are very complex sometimes it’s difficult to understand what is wrong in the configured condition. To understand such behaviour, we have to debug the condition evaluation.

Understanding debugging better…

Debugging is the process of finding and fixing errors or bugs in any software. There are many tools available in the market for debugging, but in the case of Teamcenter, we cannot use a third-party tool to evaluate the conditions.

At times, the client requirements are very intricate which implies lots of conditions on the business object. This all makes configuring the conditions tough. If one of the conditions fails, the first thought of a developer is to evaluate the conditions visually in BMIDE. However, this can be a time-consuming process, as each change needs BMIDE deployment. 

To tackle this challenge, Teamcenter has given a way out, once you enable debugging option, all the evaluation is recorded in the session log (sys log) file. Now the developer can analyze the log files to fix the not working condition in less time.

Solution approach…

Let’s concentrate on the solution part for debugging one of the conditions which are not working as expected.

As part of one of the requirements for controlling workflow visibility, the customer wants to implement a condition, where the workflow is not supposed to be seen by the users who are in the Tooling, Standards, and Classification department. Also, the object which is going to be part of this workflow should not have any release status on it and should not be part of any other workflow. And lastly, only the engineers and designers from the machine_parts group can submit the objects to this workflow. And, it should be visible for certain object types.

Considering our example, the BMIDE condition created is as follows:

The condition was not providing the expected results. The user from the machine_parts group with the role of Engineer/Designer was not able to see the workflow.

When we look at the condition in the BMIDE, it is difficult to evaluate this condition by just visual inspection. So, we have enabled the Debugging functionality. To enable this functionality we need to edit (please see green mark entries) the “logger.properties” file located in the TC_DATA folder.


After enabling the Debugging feature, we checked the sys logs. We observed that last_release_status is occurring two times in the session log file. So, we checked the condition and found out that last_release_status is used two times one for a null check and another for a not null check. So, we replaced “AND” with “OR” and then we observed that the condition started working properly.

Here we tried to explain the benefits of the “logger.properties” file using workflow conditions but it can be used for debugging lots of other functionalities.

Previous
Previous

Precise Data Handling with LOV

Next
Next

Gaining finer access control through attribute level changes