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.

Procedure

To assemble the archive, proceed as follows:

Development Track

Select the software components for which you want to create a software component archive.
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.
  1. Stop at First Inconsistent Component
    
    The assembly process stops as soon as it encounters an assembly error.
  2. 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 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 is not finished yet 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.
    Note
    
    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.
  3. 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.
      
      Recommendation
      
      The source DTR must be available at the time of import.
      
      Note
      
      We recommend this assembly option for source code transports within a CMS domain.
  4. 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.
      
      Note
      
      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.
Choose Assemble. CMS creates the new software component archive and enables it to be transported.

Transporting using CTS

Select the software components (SCs) for which you want to create a software component archive.
Choose Assemble Component(s)… The Assembly Options dialog box appears.

The detailed Assembly Options dialog box is collapsed by default.

In case a track is configured for CTS transport, the CTS Transport dialog is displayed, where a Transport Request, Description and Owner is shown depending on the TMS parameter.
Choose Assembly and Attach for transports to the CTS.

A confirmation dialog comes up with the text Software Component Archives successfully attached to Change and Transport System - Transport Request <Transport Request Name>.
Choose Follow CTS Request button to release the open Transport Request in the Transport Organizer Web UI or click the Cancel button in case automatic release is configured for this system.

For more information, see 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:

Select the software components for which you want to create a software component archive.
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.
    Note
    
    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.
  
  Note
  
  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.
    
    Note
    
    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.
Choose Assemble. CMS creates the new software component archive and enables it to be transported.

Result

You have created a new software component archive.

More Information

Package Types

Quality Assurance (Approval)