Creating a Software Component Archive (Assembly) 

Use

You create software component archives in the assembly step of the Transport Studio. This step extracts the current state of the software in the DTR workspace of the consolidation system, gets the required archives from CBS, and uses these to assemble a uniquely defined state of the software component.

For an XI track, you assemble a deliverable software package in the assembly step.

The assembly process packs the software component into an archive of type Software Component Archive (SCA). Depending on which package type you chose for the software component when you configured the track, this archive contains either source code, build and deploy archives, or both. You can then transport the archive into the test system or production system. This archive can also be shipped and imported into a follow-on track (after it has been approved on the Approval tab page).

Prerequisites

You have developed a software component and transported the developments from the development system to the consolidation system in the Transport Studio.

We recommend that you test the development state in the consolidation runtime system; only if these tests are successful should you assemble the software component archive.

You must also make sure that all development components (DCs) have been built successfully in the Component Build Service (CBS) (see Administration of Server Content in CBS).

You are on the Assembly tab page.

Procedure

To assemble the archive, proceed as follows:

Development Track

...

       1.      Select the software components for which you want to create a software component archive.

       2.      Choose Assemble Component(s)… The Assembly Options dialog box appears.

You use the assembly options to control the way software component archives are created. The following options are available:

Patch Name
You can choose your own name for the patch or accept the default.

Anonymize Users (for final assembly tracks only)
You can use this option to make the author names in the source code files anonymous for the software shipment.

Assembly Mode
You specify criteria for the archive assembly here and decide on an error tolerance level.

○       Stop at First Inconsistent Component
The assembly process stops as soon as it encounters an assembly error.

○       Skip Inconsistent Components
The assembly process skips inconsistent software components and attempts to assemble the next software component archive, so enabling as many of the selected SCAs as possible to be created.

You use the checkboxes in the Handle as Inconsistency group to define which assembly errors stop the assembly. All categories are selected by default:

■       Broken DC
The SC contains broken DCs at assembly and is therefore technically inconsistent (see also Using the CBS Buildspace Details View). Find the cause of the error, correct it and restart the assembly.

■       Dirty DC
The SC contains dirty DCs at assembly. This means that the last SC build process has not yet finished or was stopped in an inconsistent state (see Using the CBS Buildspace Details View) Find the cause of the error, correct it and restart the assembly.

■       Open Request
At assembly, the SC still has open build requests waiting to be processed in CBS. Wait until CBS has processed all requests and restart the assembly.

■       Pending Activity
The SC consolidation workspace still contains pending activities. To remove this error, check in the pending activities and activate them. Start the assembly again.

■       Invalid or Missing SDA
CMS checks whether the existing DCs are available in SDA format and whether the content of the SDAs is deployable. SDAs can be missing if CMS has not yet been able to build a DC. Correct any inconsistencies and restart the assembly.

■       Unresolved Repository Conflicts
The SC consolidation workspace contains unresolved conflicts from back transports. To remove this error, resolve the conflicts and activate them. Start the assembly again.

If you deselect an inconsistency category, CMS creates the SCA and ignores any errors in this category that arise. This means that the internal consistency of the SCA can no longer be guaranteed.

Include Modifiable Sources
You can select this option if you have configured Source or Source and Archive as the package type. You can set the following options for the insertion of source code in the SCA:

○       Include Modifiable Sources in Archive
The assembly process physically adds the source code of the SC to the SCA. You can transport this SCA into other tracks independently of the location of the repository of the consolidation workspace, or ship the SCA to the customer.

○       Include Source Pointer in Archive
DTR selects the current source code in a workspace and performs only a logical export using source pointers. This means that the assembly process only inserts pointers to the source code into the SCA; these pointers enable access to the source code in further tracks. This option significantly reduces assembly runtimes.

This option also only selects source code that has been modified since the last assembly and only exports the delta to SCA. This significantly reduces import times if you have already imported predecessor versions.

The source DTR must be available at the time of import.

We recommend this assembly option for source code transports within a CMS domain.

Support Package Number
You use this option to determine the number of the Support Package created in the assembly. You have the following options:

○       Retain Last Support Package Number
The existing Support Package number is retained. The SCA has the same number as in the last assembly.

○       Increment Support Package Number by 1
CMS raises the Support Package number by 1 in assembly. This creates a new Support Package in your maintenance cycle.

If you only want to assemble a single SC, you can enter a Support Package number of your choice in the Set Support Package Number to <Number> field. We recommend that you only use numbers higher than the number of the last assembled Support Package.

You can also specify a number for the patch level of the SC. You can enter your choice of number in the Set Patch Level to <Number> field. We recommend that you only use numbers higher than the number of the last assembled patch.

       3.      Choose Assemble. CMS creates the new software component archive and enables it to be transported.

Transporting using CTS

...

       1.      To transport the assembled files with the Change and Transport System (CTS) of Application Server ABAP (AS ABAP), choose Attach from History…

       2.      In the dialog that appears, choose the SCA files to assemble for transport to the CTS.

       3.      Choose Attach…and complete the dialog.

More information: Transports in Heterogeneous SAP System Landscape.

XI Track

In an XI track, you create the software component archive with different options. To do this, proceed as follows:

...

       1.      Select the software components for which you want to create a software component archive.

       2.      Choose Assemble Component(s)… The Assembly Options dialog box appears.

The following options are available:

Patch Name
You can choose your own name for the patch or accept the default.

Assembly Mode
You specify criteria for the archive assembly here and decide on an error tolerance level.

○       Stop at First Inconsistent Component
The assembly process stops as soon as it encounters an assembly error.

○       Skip Inconsistent Components
The assembly process skips inconsistent software components and attempts to assemble the next software component archive, so enabling as many of the selected SCAs as possible to be created.

You use the checkbox in the Handle as Inconsistency group to define whether repository errors stop the assembly. The inconsistency category is selected by default:

■       Unresolved Repository Conflicts
The SC repository contains unresolved conflicts from back transports. Resolve the conflicts. Start the assembly again.

If you deselect an inconsistency category, CMS creates the SCA and ignores any errors that arise. This means that the internal consistency of the SCA can no longer be guaranteed.

Subset Assembly (for single SCs only)
This option is selected by default in the XI track if you are assembling a single SC. The CMS checks whether individual change requests exist for the SC and displays them in the Change Requests list. You can select individual change requests from the list and then assemble them.

If there are no change requests in the assembly queue, you see the message Full assembly of component will be executed (no changelist available) instead of the list.

Support Package Number
You use this option to determine the number of the Support Package created in assembly. You have the following options:

○       Retain Last Support Package Number
The existing Support Package number is retained. The SCA has the same number as in the last assembly.

○       Increment Support Package Number by 1
CMS raises the Support Package number by one in assembly. This creates a new Support Package in your maintenance cycle.

If you only want to assemble a single SC, you can enter a Support Package number of your choice in the Set Support Package Number to <Number> field. However, you can only use numbers higher than that of the last assembled Support Package.

       3.      Choose Assemble. CMS creates the new software component archive and enables it to be transported.

Result

You have created a new software component archive.