*Under Construction* ERM Doors Next Module Structure Integrity Check during change set delivery

Authors: DianaKraaijeveld
Build basis: ERM Doors Next, version 7.0.3, 7.1 and up

Information on how to enable and use the ERM Doors Next 'Module integrity check during change set delivery' feature. Enabling this feature will enforce a data consistency check on module structures for modules that get updated by a changeset delivery.

Enabling module integrity check during change set delivery

In Doors Next v7.0.3-Ifix015 and v7.1-Ifix004, an advanced property was introduced, called Enable module integrity check during change set delivery. It can be set to true by a Jazz Admin in the /rm/admin >Advanced Properties, under 'RM Delivery component':

Activating this feature does not require a server restart.

Note Before enabling this feature, we strongly recommend to check your modules in your active streams. See this technote for more details

Deliveries done in the RM UI

If the is property is enabled, the module structure of each module that will be updated by the delivery, will be checked for inconsistencies that will occur if the delivery is processed. This check occurs in the background by the Module Analyser. It checks if modules (will) have a structure inconsistency after the delivery. If it finds any, it will check these modules in the source configuration, the current target stream and the future target stream. -This check happens after clicking the 'Deliver' button. -This check happens for all types of deliveries.

If a problem is found for a module, a message will pop up with information about the module and the configuration. When the warning shows up: -Clicking on Cancel will cancel the delivery. -The delivery will proceed when clicking on OK.

Example where the delivery is causing a module structure inconsistency in the target:

Example where a module structure inconsistency is caused by a problem in the source configuration:

Deliveries done with API

The property dng_config:checkModuleIntegrity was introduced to control the integrity check from the client’s side as part of the API call:

-If set to true: A module structure check is run as part of the API delivery. If a structure issue is detected, the delivery will fail with information on the relevant module(s).

-If it’s set to false: A module structure check is not run as part of the API delivery.

-If it is not set at all: The default is False, so a module structure check is not run as part of the API delivery.

Note that this property can only be used when the rm advanced property Module integrity check during change set delivery is also set to True.

Example body request when triggering the delivery PUT with a delivery including a Module structure issue:

You can see here that the delivery integrity is set to true :

What to do when a warning shows for one or more modules

• Copy the URL(s) of the module(s) reported by the warning.
• In a new tab, browse to the URL(s). The module will open.
• Make a note of the module ID and also make a note (or screenshot) of the project, component and local source and target configurations.

Weather or not to continue with the delivery, depends on the warning, and on what process you internally agreed with the users.
For example:

• If the warning shows that module structure inconsistency is caused by a problem in the source configuration, you may want to Cancel the delivery and first repair the module in the source configuration. And then run the delivery again.
• If the warning shows that the module will be affected in the future target only, you may want to continue with the delivery and repair the module afterwards.

Repairing the reported module(s):

• Module structure inconsistencies can be repaired by a JazzAdmin user, using the Module Analyses Tool. This tool can be found in /rm/admin >Debug >L3 Tools. See this Video on How to run the Module Analyses Tool
• In the tool, the admin can select the relevant project, component and configuration, select 'List Modules', find the relevant module, and run the Module Analyse tool for the module.
• If any doubt on which repair option to pick: Open a support ticket and provide the full module analyze output + a screenshot of the warning msg + the relevant source and target configuration names and URL's, along with the relevant audit log.

Audit logging

• How to edit the log4j2.xml file

To enable the delivery audit logging you must modify the log4j.xml file.
This can be done directly on the file system by modifying _path to the JTS Server_/server/conf/rm/log4j.xml
- or -
Modify the log4j2.xml file in the GUI on the /rm/admin >Debug >Logging >Configure Loggers page. At the bottom of the screen you'll find: RM Log4j2 Text-based log configuration. When making the modification here, make sure to click on 'Submit' when done, to save the changes.

• Modify the log4j2.xml file to enable the Delivery Audit Logging

Note Make sure to backup your current log4j2.xml file before making any changes.

• • In the Appenders section, add the following:

          <RollingFile name="rmDeliveryAuditLogFile"
                 fileName="audit/${app}-DeliveryAudit.log"
                filePattern="audit/${app}-DeliveryAudit.%d{yyyy-MM-dd}-%i.log">
               <PatternLayout>
                    <pattern>${pattern}</pattern>
                   <charset>UTF-8</charset>
               </PatternLayout>
               <Policies>
                  <TimeBasedTriggeringPolicy interval="1" />
                  <SizeBasedTriggeringPolicy size="10 MB" />
               </Policies>
               <DefaultRolloverStrategy max="5" />
          </RollingFile>
          

• • In the Loggers section, add the following:

          <!-- Delivery Logger -->
             <Logger name="rmDeliveryAuditLogger" additivity="false" level="INFO">
             <AppenderRef ref="rmDeliveryAuditLogFile" />
          </Logger>
          

• How it works

• • Delivery audit log file: rm-DeliveryAudit.log. Delivery audit logging is written to this file.

• • Size Trigger: When file reaches 10 MB, it rolls to rm-DeliveryAudit.2026-04-01-1.log
    • New active file created: rm-DeliveryAudit.log
    • Index %i increments: 1, 2, 3...

• • Time Trigger: At midnight → date changes in pattern %d{yyyy-MM-dd} -Next rollover: rm-DeliveryAudit.2026-04-02-1.log -Index %i resets to 1 for the new day

• • max="5": Keeps a maximum of 5 rolled files per day; oldest deleted when limit reached

• • Example Sequence: rm-DeliveryAudit.2026-04-01-1.log (first 10 MB) rm-DeliveryAudit.2026-04-01-2.log (second 10 MB) rm-DeliveryAudit.2026-04-02-1.log (new day, index resets)

Sub-Section text Sub-Section text Sub-Section text Sub-Section text Sub-Section text Sub-Section text Sub-Section text Sub-Section text Sub-Section text Sub-Section text Sub-Section text

Related topics: Deployment web home, Deployment web home

External links:

• IBM

Additional contributors: TWikiUser, TWikiUser