IBM Rational Publishing Engine Support for DOORS DXL Security

1. IBM Rational Publishing EngineSupport for DOORS DXL Security Dragos Cojocari April 2011

2. Overview • DOORS 9.3 DXL Security • Restriction on the location of include files • Restrictions on the location of DXL files ( batch mode only) • RPE 1.1.1.2 Objectives • Run with all previously supported DOORS versions • Run with DOORS 9.3 in unsecure mode • Run with DOORS 9.3 in secure mode

3. Changes in RPE • RPE 1.1.1.1 and older • DXL scripts are generated in the user’s temp folder to configure the DXL execution • The temp DXL contains information such as module path, view name, baseline version and the name of the attributes that are to be extracted from DOORS • These scripts will no longer work with a DOORS 9.3 in secure mode • RPE 1.1.1.2 • All RPE’s DXLs are static ( deployed by the RPE installer) • RPE provides the runtime details to the DXL environment through an XML file • The path of the XML file is defined in the RPE_DXLARGUMENT system variable • The DOORS addins registry value is updated by the RPE installer to include the path to RPE_HOME • If DOORS is installed after RPE the addins registry key will not be created. You need to create it manually or re-run the RPE installer. • NOTE: there is a know issue with the RPE 1.1.2 installer that does not create this key in repair/update mode

4. RPE_DXLARGUMENT • When accessing DOORS though COM ( new_instance=false) only one user can run a document generation as there is a unique value for RPE_DXLARGUMENT • Accessing DOORS though COM is not supported for concurrency in RPE. This is why RPE WebService always access DOORS in batch mode • The variable is not used for COM access as the Java code and DXL code assume that the path is %TEMP%\RPE\rpe_doors.xml. This removes the need of creating a new system variable in the user’s ebvironment. • When accessing DOORS in batch mode ( new_instance=true) RPE will generate a unique value for the RPE_DXLARGUMENT for each DOORS process it spawns. This allows concurrent requests to be processed as before. • The variable is automatically created by RPE for batch mode (new_instance=true) • The generated value is in the form: %TEMP%\RPE\rpe_doors_<UNIQUESTRING>.xml • The variable “lives” only for the duration of the spawned DOORS process

5. Default installation • Will work as is for DOORS 9.2 and older and for DOORS 9.3 in unsecure mode • Check “common problems” for problems and their resolution • Will work with DOORS 9.3 in secure mode if • RPE_HOME is in the list of trusted addins location as defined in the DOORS Server properties • RPE_HOME is a trusted “batch files path” location in the DOORS Server properties • Check “common problems” for problems and their resolution • RPE can handle different scenarios as the above is not guaranteed to be the situation in a production environment. A set of 1 time tasks must be performed by the System Admin.

6. Custom installation for DOORS 9.3 in Secure Mode • Server side: copy the “Source” subfolder from the RPE Installation folder in one of the “Addins Path” locations specified in DOORS DB – DXL Security property. As RPE references its included files using relative paths the DOORS DXL runtime will be able to retrieve them. • The folder structure must be preserved. The source folder cannot be renamed • Server side: copy the “Source” subfolder from the RPE Installation folder in the location specified by “Batch files path” property in DOORS DB – DXL Security property • The folder structure must be preserved. The source folder cannot be renamed • Define the RPE_DXLLOCATION ( double L) variable to point to the “Batch files path value”. RPE will then use this location as startup location for its DXLs instead of the default RPE_HOME. • This value can be set through the RPE silent installer

7. RPE_DXLLOCATION • Silent installer example for RPE 1.1.1.2 • msiexec.exe /i “<path to msi>" /qn INSTALLDIR=“<install dir>" LAPAGREE="Yes" RPE_DXLLOCATION=“<TRUSTED DXL LOCATION PATH>“ • The <TRUSTED DXL LOCATION PATH> • Example: \\Arakis\DOORS\trusted_dxl • Must be the same path as the one in the DOORS DB properties • Must be an absolute path ( cannot contain system variables) • Example of bad value: %DOORS_SERVER%\DOORS\trusted_dxl where DOORS_SERVER = \\Arakis • Must be an UNC path. It cannot be a mapped drive letter as drive mappings are user specific and will not work from all user accounts including the Local System account used by NT Services such as the Tomcat service • Example of bad value: Z:\trusted_dxl where Z: = \\Arakis\DOORS • The path must not end with a “\”

8. Running as a WebService • Install RPE 1.1.1.2 or newer on the machine hosting the RPE WebService • Define the RPE_DXLLOCATION variable if installation is manual • Deploy the RPE WebService

9. Test Environment • a standard user that has no “Edit DXL” powers • all DOORS DXL security options used

10. Common Problems • DOORS 9.x is not in secure mode but RPE throws errors • Errors look like bellow • "E- DXL: <Line:3> could not open include file (source/DOORS/dxl/schema discovery/const.inc) (No such file or directory)“or-E- DXL: <D:\CAx\Rational\Publishing Engine\1.1.1.2\source\DOORS\dxl\doors driver\getDOORSVersion.dxl:3> could not open include file (source/DOORS/dxl/doors driver/getDOORSVersion.inc) (No such file or directory) • Solution • Check if DOORS is started using command line arguments that override the addins path. If that is the case either add the path to RPE installation there or copy RPE source folder to the path pointed by the addins command line flag • Check if HKEY_CURRENT_USER\SOFTWARE\Telelogic\DOORS\9.3\Config\addins exist as that value overrides the HKEY_LOCAL_MACHINE\SOFTWARE\Telelogic\DOORS\9.3\Config\addins set by RPE. If the HKEY_CURRENT_USER value exists add the path to the RPE installation in it