How Does Dimensions Build Collect Outputs?

When a build is launched on a build node, the PBEM (Primary Build Execution Monitor) sends SOAP (Simple Object Access Protocol) messages to the build server at predefined intervals. These messages notify the build server when the build has started and finished, and when the build of an individual target or build step has also started and finished. These messages include logging information from the build step, such as std out and
std error, and the Bill of Materials (BOM) report from an individual target or build step, if it is available. During a build, start and finish messages are issued that contain supporting logs and a BOM report for each target that is built.

When a request is made to collect targets from a build, the build server processes each step/target completion message and BOM report to determine which files need to be collected back into Dimensions. The build server perform this task this immediately so that outputs are being collected while the build is running, spreading the network, appsrv, and libsrv load across the build process.

For each target item in a BOM, the build server determines the filename of the item and any secondary files, such as listings, that need to be collected. The build server combines these with attributes from the configuration, such as the design part for the target, and makes a request to the appsrv to store these files in the repository. The appsrv determines whether the file being preserved is a new or existing item, compiles the information required to complete the process, and stores the item in the repository. The appsrv also creates "made of" records in the database for impact analysis and build target calculation by the Dimensions clients.

For build steps that do not produce a BOM report, mainly on distributed platforms, the appsrv collection logic searches the build area matching the file patterns that are provided by the build configuration. All items that match the search patterns are placed in the repository and "made of" records are created.

After the appsrv has stored the items, it sends the item specifications and filenames to the build server. This information is stored in a cache on the build server and used to supplement metadata deficiencies from the BOM data in subsequent build steps. Because output collection is running asynchronously from the build, a final target that has a dependency on an intermediate target created earlier in the same build job may not have the proper metadata information for the intermediate target. This is because the output collection, and the updating of the local metadata, may not have run by the time the final target was being built. The missing metadata information is added by the build server using the local cache it maintains throughout the build of items that have been processed during this build job.

The above process is executed repeatedly until all outputs are collected for a given build job.

Build Support

When an output collection is invoked for each completed build step the target files are collected into a temporary changeset. When the build is complete this changeset contains all of the collected targets for the current build request. When the build server is notified by the PBEM that the build is complete, it notifies the Dimensions server that the temporary changeset can be merged into the stream or project. When the merge occurs request relationships are created. If an error occurs during processing, the temporary changeset is not deleted and a message is returned to the build server log. You can use the DBT (Deliver Build Targets) command to reattempt the delivery at a later time.

Redelivering a Failed Delivery

If a delivery fails, use the DBT command to reattempt the delivery. For details, see the Command-Line Reference.

Contents of Temporary Changeset

When a build is complete, the temporary changeset that was used contains all the build targets. Using the "made-of" relationships as a guide, only the build targets used during the delivery are added to the XML file because the source files should already exist in the stream. If these relationships are incorrect or not complete, set the following variable in dm.cfg to TRUE to force all items from the project (sources and targets) to be added to the delivery XML:

DM_BLD_MERGE_ALL_ITEMS