1

This presentation is divided into three chapters. Each chapter covers a particular
tool: the Solution Builder, the Solution Manager, the Business Configuration Set,
and the Extended Computer Aided Test Tool.

The following slides demonstrate what tools are used for activation and data
import of preconfigured content.

Note: You can also configure a SAP Rapid Deployment Solution or SAP Business
All-In-One Solution manually using additional configuration guides, as described
in the Quick Guide belonging to each solution package.

Lets begin with the powerful Solution Builder.

We will get an idea of the structure of the Solution Builder and its scoping,
personalization, activation, and packaging functionalities.

The automated activation with the Solution Builder tool helps to reduce the time to
value and cuts down costs and resources for the implementation.

Scoping

You define the scope of a solution you want to implement, by selecting the
relevant scope items, e. g. business processes, from the scopes offered by the
relevant solution packages. If the implementation scope is defined, you start the
finalizing process, that copies the relevant configuration content to your system.

Personalization

You can personalize the generic customizing settings contained in the

configuration content according to the enterprise's needs. The personalization
process covers enterprise structure settings and further basic settings.

Activation

If you start the activation process, the system writes the configuration content to
the system tables (application and customizing tables). The activation process
may prompt you to manually add settings or to intervene in the case of errors. You
can monitor the progress of the activation process on the level of tasks defined
per building block.

Lets take a closer look at different types of solution builder user groups. The
consulting user wants to define the scope of a solution and activate this solution
easily and rapidly. The presales user needs to see the scenarios and a description
of their content, and define a scope. Neither of these users needs deep
knowledge on technical details, such as the technical structure of the scenario and
the respective building blocks, or a rich understanding of the activation tools.

On the other hand, a development user needs to see the technical structure of the
scenarios and building blocks. This user type is able to develop own building
blocks, scenarios, and solutions.

According to different roles and tasks mentioned above, the consultant and the
presales user mainly work in the solution editor and, during the activation, in the
Implementation Assistant. The development user has a clear focus on the Building
Block Builder, but also benefits from using the Implementation Assistant for the
actual activation.

The structure of the solution builder tool reflects the structure of a preconmfigured
package (RDS, BAiO). As shown here, a solution consists of a specific number of
scenarios, and a scenario contains a certain number of building blocks.

10

The solution scope is a set of scenarios. One set of installation data files belongs
to a solution.

The scenarios can be selected and deselected by the consultant during the
scoping phase.

The scenarios contain a certain number of building blocks. Building blocks are the
smallest logical units in the package varchitecture. A building block includes
customizing and master data steps for the respective piece of business content.

11

All the tasks connected with the solution scope are accomplished in the Solution
Editor. Scenarios can be changed or activated in the scenario view of the
Implementation Assistant. As the name of the Building Block Builder already points
out, building blocks can be changed, copied, and created with its help.

12

In the Solution Editor, different scopes can be activated and changed. A graphical
scoping engine can be used and sample data, such as organizational structure,
can be adapted before scope activation.

Application areas can be assigned to the scenarios in the Solution Editor. This
determines how the scenarios are presented in the solution map in a graphic view.
In the Solution view of the Implementation Assistant, entire solutions can be
activated, and the respective logs can be accessed. In the scenario edit view,
scenarios can be created, documents can be attached to a scenario, and building
blocks can be assigned to the scenarios.

In the Building Block Builder, building blocks can be created, and customizing and
master data steps can be added to a building block. The uploaded external text
files in which the installation data is stored can be maintained in the Building Block
Builder.

13

Depending on the role and tasks of the user (scoping, personalization,

development, or activation) it is possible to switch between the different
components of the solution builder.

14

Lets summarize the main capabilities of the solution builder.

The tool enables partners to select, personalize, and activate scope items in the
SAP system, thereby reducing implementation time and cost.

15

For the RDS Solutions you can navigate to the Solution Builder Add on via the
Step-by-Step Guide.

16

After installation of the add-on, start the Solution Builder with Transaction
/n/smb/bbi

17

18

A Solution ManagFor Rapid Deployment solutions (RDS)content is provided as

templates with the regular Solution Manager implementation content add-on (STICO, ST-RDS).

The Solution Manager template and a Solution Builder Solution are interrelated
enabling a seamless integration of both tools during the deployment phase of an
RDS.

19

The Solution Builder Tool and the Solution Manager Tool are integrated: after the
selection of a template in the Solution Manager this scope can be automatically
transferred to the Solution Builder. Then the scope is activated in the Solution
Builder. Finally further refinements can be made in the system starting from the
Solution Manager.

20

Next, we will discuss Business Configuration Sets and how they are used.

21

We will cover the definition, structure, features of variable fields, and benefits of a
Business Configuration Set.

22

After completing this lesson, you will be able to:

Define a BC Set

Describe the activation of BC Sets in the Solution Builder

Explain the structure, characteristics, and benefits of BC Sets

Activate a BC Set in transaction SCPR20

23

Imagine that BC Sets are snapshots of the existing customizing in the system.
This customizing can be transferred to other systems.

24

A BC SET groups customizing settings according to their logical and business

criteria. Customizing included in a BC Set is like a copy of the IMG settings. This
means that the original customizing in the system is not referenced by the BC Set.
If you change your customizing after the creation of your BC Set, the BC Set
content will not be influenced by that action.

A BC Set is client-independent and is therefore accessible across the system

landscape.

A BC Set can be downloaded and uploaded again as a local file.

A BC Set can be used for quality assurance and documentation purposes. You
can also attach documentation to a BC Set.

25

Certain objects cannot be included in a BC Set, namely master data, transaction

data, repository objects, address data, and number ranges.

26

In the solution builder, BC Sets are activated. The activation of BC Sets imports
the customizing that is included in the BC Sets. The actual customizing values are
stored in text files from where they are imported. The BC Sets merely serve as
placeholders, and all the fields are variable inside the BC Set.

Lets talk about the concept and structure and some characteristics of the BC Set,
so that it is easier to understand how the sample customizing is imported via the
solution builder.

27

This snapshot shows a BC Set in transaction SCPR3. When you double-click on a

BC Set name, different tables that the BC SET is covering are displayed on the
right side of the screen.

If you double-click on different table names, the content of the tables in the system
is displayed in the lower part of the screen. Here, the values of all the single fields
appear.

28

In a BC Set, attributes can be assigned to single customizing fields.

Fixed attribute means that the value of the customizing field cannot be changed
after activation. This is important, for example, for preconfigured solutions for
multinational rollout. Customizing must not be changed by subsidiaries, but is
defined by global headquarters.

Variable attributes mean that during the activation, these values can be changed
just after choosing Activate and before the actual import of the values.

A default value is imported into the system and can be changed after the
activation of a BC Set.

29

Here you can see the main transaction, SCPR3.

In this transaction, BC SETs can be created, copied, deleted, and changed. They
can be uploaded and downloaded and compared with the customizing tables.

You can check key conflicts and call where-used lists of a BC Set.

Note: To learn how to create BC Sets, please refer to unit Packaging, Deployment
& Rollout of SAP Business All-in-One Partner Solutions.

30

There are a number of differences between the transfer of customizing between

systems via transport requests on the one hand, and using BC Sets on the other
hand.

The main difference is that in a transport request, it is only possible to transport

table lines, whereas in a BC Set, it is also possible to transport single fields.

The BC Set data can overwrite entries in the customizing tables or insert new
entries. The actual procedure depends on the selected activation options.

If entries with the same key already exist, a transport request transmits entries
into the customizing tables; the new transport request entries overwrite the old
ones.

In the case of a BC Set, you can check which data will be overwritten during the
activation before you activate a BC Set.

31

There are many advantages when BC Sets are used to transfer customizing.

It is possible to set customizing settings as default, variable, or fixed values inside

the BC Set during the creation of the BC Set.

Variable values allow flexible adjustment of predefined customizing. Before the

activation of a BC Set, the values of variable fields can be changed. Customizing
can be archived and documented in a BC Set.

A simple consistency check is possible via the Customizing Cross-System Viewer.

The content of a BC Set and the system can be compared. BC Sets are quickly
available by uploading and downloading them as a local file.

32

Please check in the corresponding Quick Guide of the SAP Rapid Deployment
Solution if switching to the BC SET API is possible.

33

Next, lets look at the Extended Computer Aided Test Tool, also called eCATT.

34

We will discuss the eCATT structure and an eCATT activation via the solution
builder.

35

eCATTs allow you to combine and automate business processes as repeatable

test procedures

eCATTs are cross-client. That means they can be displayed and run in any client
of a system.

An eCATT uses the batch input interface to import data.

eCATTs provide flexible data management by using parameters and variables.

The eCATT tool and the Test Workbench are Basis applications. They are
available in all ABAP-based systems.

eCATTs are typically used to run automated tests and system checks and to
create master data, as well as to create transactional data, for example, for
training system preparation.

36

In the context of preconfigured packages /RDS, BAiO) , eCATTs are responsible

for the import of sample master data of the preconfigured packages that are
activated. They are activated via the solution builder.

The sample master data is stored in text files.

37

The technical structure of an eCATT consists of the following four components: Test
script, test configuration, test data container, and system data container.

The test script consists of an executable script and an interface for data transfer.
Transactions and commands in the SAP system can be recorded, and you can perform
further editing using ABAP scripts.

Test configuration is a central object of an eCATT mechanism and contains a set of

references to a test script, and possibly several test data containers. Here, you can set
the link between test script, test data container, and system data container, and control
the running mode.

Test script and test configuration are required eCATT components. Test data container
and system data container are optional eCATT components.

In the test data container, you can fill in reusable data (for example, organizational unit)
which are imported when running the test configuration. This object contains a set of
parameters that can be maintained independently of a test script. Parameters can be
ABAP simple types, structures, or tables. In the case of SAP rapid Deployment Solutions
and SAP Business All-in_One Solutions the reusable data is stored in text files.

The separation of test script and test data allows for a considerable degree of re-use.

In the system data container, you can reference reusable system data so that it can be reused for all the eCATTs.

We will now look at the test script and the test configuration in more detail.

38

In terms of its structure, a test script is similar to a function module. It contains

various attributes, an interface in the form of importing and exporting parameters,
and the commands that actually form the test. Scripts may also contain local
variables for use within the coding.

General settings such as title, package, person responsible, component, and the
like can be set in the attributes for an eCATT.

Different types of parameters (import parameter, export parameter, or variables)

may be set in an eCATT to control the testing procedure,and perform the interface
between test script and test data container.

Variable commands can be performed in the test script, from transaction recording
to ABAP script and function calling.

39

The test configuration includes a link to the test script and to the test data
container.

Basic attributes can be set for testing configuration to control the general
characteristics of the testing procedure.

You can assign data to a configuration by:

Entering it manually in the variant grid

Pasting it into the grid from an external source

Uploading it from a tab-delimited text file

The system data container can be linked so that general data can be re-used for
different eCATTs.

You maintain the external data file via the Solution builder.

40

41

42