Debugging BMIDE Conditions in Teamcenter: A Practical Guide

What Are BMIDE Conditions?

In Teamcenter, the Business Modeler IDE (BMIDE) is the tool used to define and manage the data model — but its scope extends well beyond object type definitions and property declarations. One of its most powerful and often underutilised capabilities is the BMIDE Condition framework.

Conditions allow administrators and architects to control the applicability of business rules based on contextual factors — the type of object being operated on, property values, the user's group or role, and the relationship between objects. Rather than applying a rule universally, conditions let you apply it selectively and precisely.

Common scenarios where BMIDE conditions are used include:

Controlling which Naming Rules apply based on group, role, or object type
Restricting GRM (Generic Relationship Management) Rules — governing which objects can be related and how many
Managing workflow template visibility — showing only relevant workflows to the right users and objects
Driving LOV (List of Values) applicability based on context
Controlling Extension and Operation attachment — which custom code hooks fire under which circumstances

Used well, conditions make a Teamcenter configuration clean and scalable. Used without discipline, they become a source of hard-to-diagnose issues — particularly when multiple nested conditions interact in unexpected ways.

Types of Conditions in BMIDE

Teamcenter provides two primary condition types within BMIDE, each serving a distinct purpose in controlling system behaviour.

1

Action Conditions

Triggering behaviour

Action conditions control whether a specific action or event is triggered based on the state of the data or object. A common use case is extension attachment — determining whether a pre or post-action on an object lifecycle event (such as CREATE or SAVE) should fire, based on conditions evaluated at runtime.

For example, an action condition might restrict a SAVE pre-extension to only fire when the object belongs to a specific object type and the user is in a particular group.

2

Validation Conditions

Enforcing rules

Validation conditions enforce business rules and data constraints on specific object types or property values. A widely used application is workflow template visibility filtering — using a condition to determine whether a given workflow template is shown to a user when initiating a process on an object.

For example: "Show this Change Notice workflow only if the object has no current release status, is not already participating in another workflow, and belongs to a user with an Engineer or Designer role in the machine_parts group."

Nested conditions: Conditions can be combined and nested using AND / OR logic to create compound rules. This power is also the primary source of debugging difficulty — a single logical error in a nested structure can cause the entire condition to evaluate incorrectly.

The Debugging Challenge

Conditions in BMIDE are defined visually within the BMIDE editor. For simple conditions — a single group check, a single property value test — visual inspection is usually sufficient to identify a fault.

The problem emerges when conditions become complex: multiple AND/OR combinations, nested subconditions, conditions that reference release status, workflow participation state, object properties, and role/group membership simultaneously. At that point, visual inspection is no longer reliable. The condition may appear logically correct in the editor but evaluate incorrectly at runtime due to a subtlety that isn't obvious from the tree view alone.

The conventional response to this is trial-and-error modification in BMIDE — changing the condition, redeploying to the server, testing behaviour, and repeating. Each BMIDE deployment cycle takes time, creates deployment risk in shared environments, and still may not isolate the root cause clearly.

The key limitations of visual-only debugging:

No visibility into which branch of a compound condition is evaluating to true or false at runtime
No trace of the actual property values being tested against during condition evaluation
Each change requires a full BMIDE deployment — time-consuming in production-adjacent environments
Risk of introducing new issues while investigating the existing one

Teamcenter provides a purpose-built solution to this problem: condition evaluation logging via the logger.properties file.

Enabling Debug Logging for BMIDE Condition Evaluation

Teamcenter's logging infrastructure includes the ability to capture condition evaluation detail in the server-side session log (syslog). When enabled, every condition evaluation during the session is recorded — including which sub-conditions were assessed, what values were tested, and how the overall condition resolved.

The logging behaviour is controlled by the logger.properties file located in the TC_DATA folder.

Locating the logger.properties File

The file is located at: %TC_DATA%\logger.properties

This file controls the verbosity and scope of Teamcenter server-side logging across multiple subsystems. For condition debugging, the relevant section is the BMIDE condition evaluator logger.

logger.properties file open in a text editor showing BMIDE condition logging entries to be enabled — Screenshot: The `logger.properties` file open in a text editor, showing the BMIDE condition logging entries that need to be enabled.

What to Enable

Add or uncomment the relevant logger entries for BMIDE condition evaluation. With logging enabled, condition evaluation detail will be appended to the session's syslog file during active Teamcenter sessions.

Environment note: Enable this logging in a development or test environment. Condition evaluation logging is verbose and should not be left enabled in production, as it increases syslog file size significantly and can affect server performance under load.

Reading the Output

Once logging is enabled, reproduce the scenario where the condition is not behaving as expected. The syslog will capture the step-by-step evaluation trace. You can then open the syslog and search for the condition or object type name to locate the relevant entries.

Worked Example: Debugging a Workflow Visibility Condition

To illustrate the debugging approach, consider the following real-world scenario. A workflow visibility condition has been configured with these requirements:

The workflow template must not be visible to users in the Tooling, Standards, or Classification departments
The target object must have no current release status applied to it
The target object must not already be participating in another active workflow
Only users with an Engineer or Designer role in the machine_parts group may initiate the workflow
The workflow must only appear on specific defined object types

The Configured BMIDE Condition

A compound condition was built in BMIDE incorporating all five criteria above, using nested AND logic. The condition was deployed and associated with the workflow template's filter condition in the Workflow Designer (Start Task → Display Task Attributes Panel → Filter Condition).

Full BMIDE condition tree showing all five criteria configured as nested AND sub-conditions — Screenshot: The full BMIDE condition tree as configured — showing all five criteria as nested AND sub-conditions.

The Fault: Users Not Seeing the Workflow

After deployment, users in the machine_parts group with Engineer and Designer roles were unable to see the workflow template when working on qualifying objects. The condition was evaluating to false even in scenarios where it should have evaluated to true.

Visual inspection of the condition in BMIDE did not immediately reveal the problem. The logic appeared correct. This is the scenario where logging becomes essential.

Enabling Logging and Reproducing the Issue

The logger.properties file was updated to enable BMIDE condition evaluation logging. A session was opened as an affected user, and the workflow initiation was attempted on a qualifying object. The syslog was then reviewed.

Syslog showing condition evaluation output with two last_release_status entries visible revealing the AND vs OR logic fault — Screenshot: The syslog showing condition evaluation output with the two `last_release_status` entries visible — revealing the AND vs OR logic fault.

Interpreting the Log Output and Identifying the Fix

Reviewing the syslog revealed that last_release_status was appearing twice in the condition evaluation trace — once for a null check (object has no release status) and once for a not-null check (object has a release status).

Returning to the BMIDE condition definition with this specific clue made the fault immediately visible: the two last_release_status sub-conditions were joined with an AND operator, which logically could never be satisfied simultaneously — an object cannot both have and not have a release status at the same time.

Sub-condition	Operator used (incorrect)	Operator required (correct)	Why
`last_release_status` is null	AND	OR	These are mutually exclusive states — only one can be true at any given time
`last_release_status` is not null	AND (with above)	OR (with above)	AND requires both to be true simultaneously — logically impossible here

The Fix

The AND operator between the two last_release_status sub-conditions was changed to OR. After redeployment, the condition began evaluating correctly — users in the machine_parts group with the appropriate roles could now see the workflow template on qualifying objects.

Key insight: The syslog did not require manual interpretation of complex logic. It made the duplicated property evaluation visible at a glance — something that hours of visual inspection in BMIDE had failed to reveal. The logging output transformed a vague "condition isn't working" problem into a specific, diagnosable fault.

Best Practices for BMIDE Condition Debugging

1

Always test in a dedicated dev/test environment

Required

BMIDE condition logging is verbose. Enabling it in a shared or production-adjacent environment can generate large syslog files quickly and introduce performance overhead. Keep a dedicated Teamcenter dev environment where logging can be freely toggled without impacting other users or activities.

2

Reproduce with a minimally scoped session

Recommended

When capturing a debug syslog, open a fresh session as the affected user type and perform only the action that triggers the condition evaluation. This keeps the log file manageable and makes it easier to locate the relevant condition evaluation entries without noise from unrelated system activity.

3

Search the syslog by property or condition name

Efficiency tip

Syslog files can be large even in a clean test session. Use a text editor with search capability (or grep in a Unix environment) to locate entries referencing the specific property or object type from your condition. Search for the property internal name — e.g. last_release_status — rather than the display name.

4

Disable debug logging after resolving the issue

Important

Condition evaluation logging is a debugging tool, not a monitoring tool. Once the condition is corrected and verified, remove or comment out the debug entries in logger.properties and restart the affected services. Leaving verbose logging enabled indefinitely creates unnecessary disk usage and can mask other log entries.

5

Document complex conditions at design time

Preventive

For conditions with more than three sub-conditions, maintain a plain-language description of the intended logic alongside the BMIDE configuration. A comment like "OR logic required between null/not-null checks on release status — AND will never evaluate true" prevents the same mistake from recurring during future maintenance by a different consultant or administrator.

When This Debugging Technique Applies

The logger.properties condition debugging approach is useful across a range of BMIDE condition use cases beyond workflow visibility:

Naming Rule conditions — when a naming pattern is not applying to the expected group or object type
GRM Rule conditions — when objects that should be relatable are being blocked, or vice versa
LOV conditions — when a list of values is not appearing for the expected context
Extension conditions — when a pre or post-action handler is not firing when expected, or is firing when it should not
Display Rule conditions — when properties are showing or hiding incorrectly for specific groups or roles

Key Takeaways

BMIDE conditions control the applicability of Naming Rules, GRM Rules, workflow visibility, LOVs, and extension attachments — they are central to a well-configured Teamcenter system, and faults in them have wide impact.
Visual inspection alone is insufficient for debugging complex nested conditions. When a condition has more than two or three sub-conditions, runtime log analysis is the only reliable diagnostic method.
The logger.properties file in TC_DATA enables condition evaluation logging to the server syslog — this is Teamcenter's built-in mechanism for condition debugging and does not require third-party tools or code changes.
In the worked example, the fault was a classic AND vs OR logic error on mutually exclusive property states — a mistake that is invisible in the BMIDE tree view but immediately obvious in the syslog output.
Disable debug logging after resolving the issue. It is a targeted diagnostic tool, not a permanent configuration — leaving it enabled unnecessarily degrades performance and fills disk space.
This technique applies to all BMIDE condition types — not just workflow visibility. Any unexpected condition behaviour across Naming Rules, GRM Rules, LOVs, Display Rules, or Extensions can be investigated using the same approach.