Intland codebeamer is an Application Lifecycle Management (ALM) platform for advanced product and software development. The open platform extends ALM functionalities with product line configuration capabilities, and provides unique configurability for complex processes.

Video demonstration: https://www.enco-software.com/en/plm/#codebeamer-video

Intland website: https://intland.com/codebeamer/

Working Method

Interaction with codebeamer relies on the same basic rationale as SOX integration with IBM Doors/DNG (cf. https://enco-software.atlassian.net/wiki/pages/createpage.action?spaceKey=SUD&title=new%20IBM%20DNG%20Working%20Method&linkCreation=true&fromPageId=3440589823). The product semantics are quite similar in each case.

Several screenshots reproduced below have been edited in the interest of data protection.

Configure Synchronization

Initiate the process by right-clicking your project. Select Configure Synchronization:
Outcome: the Synchronization Editor for your current project will open.
Right-click the single entry and select New Child > CodeBeamer Projects > <Example_Project>.
Outcome: <Example_Project> will load and appear in the Editor window.
Next, you will need to import the shape definitions (artifact types) used within the ADP context. To achieve this, right-click the template and select New Child > Import Shape Definitions…
Outcome: the dialog for selection of a query executor will open:
For our example scenario, any of the three executors available will produce identical results. As soon as you have made a selection, you may add a query to be processed by the executor of your choice. This option stipulates that you are conversant with the codebeamer query language. An introduction to cbQL is out of the scope of this documentation. Please refer to cbQL (codebeamer.com) as required. The executor will dismiss any malformed query, i.e., it will not normally report any input errors.
Outcome: using the topmost executor (no hierarchy options) and no additional query parameters will load the shape definitions as suggested below:
You may now open the drill-down list to review any field/property definition. For example, it is possible to examine and, where appropriate, change a given Field Type.
Next, there exists an option to create a new Group Definition, corresponding to a codebeamer work item / tracker (i.e., a logical, hierarchical container for requirements). In the SOX context, a Group references a ReqIF document. This setup achieves synchronization of a SOX specification document with a codebeamer tracker.
Lastly, you will need to create default Item Definitions. To accomplish this, right-click the Group Definition and select New Child - Import Item Definitions. - Outcome: SOX will query the specified codebeamer tracker in order to determine which artifact types are present in the relevant requirements subset. These will be displayed accordingly.

Synchronizing Your Project

It is now possible to initiate the synchronization process. As an initial phase, you may wish to perform a Dry Run. So doing will serve the twofold purpose of familiarizing yourself with the process and interface, as well as validating your configuration settings. To achieve these objectives, right-click your SOX project and choose Synchronize (Dry Run).

Outcome: The Synchronization dialog will open.

As is evident from the menu, you have the alternative options of importing data vs. synchronizing existing data. In the context of the Dry Run, this selection is of little relevance, as the system will not really action any data transfer in either scenario. Click OK to start the process.

If, for example, you intend to export back changes to a manifest change set, you will need to supply the set’s URI here. The Global Configuration Context will be used by default if nothing is specified here.

Outcome: if there were no errors, SOX will report success.

If the Dry Run was performed successfully, you are ready to proceed with the actual synchronization. Once again, right-click your project; this time around, select Synchronize:

Outcome: the synchronization dialog will open as demonstrated before:

Again, one’s choice of Synchronization direction is immaterial if doing the process for the first time, aiming to bring the codebeamer data into SOX for possible modification. - Subsequent to confirmation with OK, SOX will commence synchronizing itself with the remote server. Note that depending on parameters like volume and transfer rate, the initial synchronization may take a number of minutes, since this performance involves some internal computation. Syncing repeated within the same session should be notably faster.

Outcome: if the Dry Run succeeded, the Synchronization is likely to complete successfully also. Hence, SOX will report success, and the Module requirements will have been loaded from codebeamer. A new document (a ReqIF specification) will have been created and will be available for editing and backwards synchronization. As noted, the initial structure will be identical to the one synchronized with, or imported from, codebeamer side.

Double-clicking the root node will open the ReqIF editor:

When synchronizing backwards any changes/additions to your data, you will be prompted for the target change set.