DoorsNextModuleIntegrityCheckForDeliveries < Deployment

Engineering Lifecycle Management Wiki - Deployment

Community information and contribution guidelines

TWiki > Deployment Web > DeploymentTroubleshooting > DoorsNextModuleIntegrityCheckForDeliveries

Revision 9 - 2026-04-09 - 17:15:23 - DianaKraaijeveld

<div id="header-title" style="padding: 10px 15px; border-width:1px; border-style:solid; border-color:#FFD28C; background-image: url(<nop>https://jazz.net/wiki/pub/Deployment/WebPreferences/TLASE.jpg); background-size: cover; font-size:120%">
---+!!  **Under Construction** ERM Doors Next Module Structure Integrity Check during change set delivery
%DKGRAY% Authors: Main.DianaKraaijeveld <br>
Build basis: ERM Doors Next, version 7.0.3, 7.1 and up
%ENDCOLOR%</div></sticky>

<!-- Page contents top of page on right hand side in box -->
<sticky><div style="float:right; border-width:1px; border-style:solid; border-color:#DFDFDF; background-color:#F6F6F6; margin:0 0 15px 15px; padding: 0 15px 0 15px;">
%TOC{title="Page contents"}%
</div></sticky>

<sticky><div style="margin:15px;"></sticky>

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':

<img src="%ATTACHURLPATH%/EnableProperty.png" alt="EnableProperty.png" width="525" height="263" />

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 [[https://supportcontent.ibm.com/support/pages/recommendations-around-enabling-erm-doors-next-module-integrity-check-during-change-set-delivery][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_.

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

<img src="%ATTACHURLPATH%/WarningDeliveryCausesFailureOnTarget.png" alt="WarningDeliveryCausesFailureOnTarget.png" width="525" height="263" />

%BR%

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

<img src="%ATTACHURLPATH%/WarningInContextOfSourceConfig.png" alt="WarningInContextOfSourceConfig.png" width="395" height="200" />



---+++ 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.

%GREEN% Example %ENDCOLOR% 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* :
%BR%
<img src="%ATTACHURLPATH%/APIdeliverySetting.png" alt="APIdeliverySetting.png" width="525" height="263" />



---++ 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.
%BR%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  [[https://www.youtube.com/watch?v=1fqOMVbYFLg][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.
   %BR%This can be done directly on the file system by modifying _path to the JTS Server_/server/conf/rm/log4j.xml
   %BR%  - or - 
   %BR%Modify the log4j2.xml file in the GUI on the <Server>/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:*
      <verbatim>
      <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>
      </verbatim>

      * *In the _Loggers_ section, add the following:*
      <verbatim>
      <!-- Delivery Logger -->
         <Logger name="rmDeliveryAuditLogger" additivity="false" level="INFO">
         <AppenderRef ref="rmDeliveryAuditLogFile" />
      </Logger>
      </verbatim>


   * *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 &#8594; 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: [[DeploymentWebHome][Deployment web home]], [[DeploymentWebHome][Deployment web home]]

---+++++!! External links:          

   * [[https://www.ibm.com][IBM]]

---+++++!! Additional contributors: Main.TWikiUser, Main.TWikiUser

<sticky></div></sticky>

Attachments

Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	APIdeliverySetting.png	manage	33.9 K	2026-02-09 - 15:13	DianaKraaijeveld
png	EnableProperty.png	manage	16.0 K	2026-02-06 - 10:36	DianaKraaijeveld	Enable Advanced Property
png	WarningDeliveryCausesFailureOnTarget.png	manage	63.2 K	2026-02-06 - 14:52	DianaKraaijeveld
png	WarningInContextOfSourceConfig.png	manage	20.2 K	2026-02-06 - 14:52	DianaKraaijeveld

Copyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.