SAP NetWeaver Identity Management Implementation Guide - Transport

  • View
    227

  • Download
    1

Embed Size (px)

Text of SAP NetWeaver Identity Management Implementation Guide - Transport

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    1/40

    SAP NetWeaver Identity Management

    Implementation guide- Transport

    Version 7.2 Rev 7

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    2/40

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    3/40

    i

    Copyright 2012 SAP AG. All rights reserved.

    Preface

    The productThe SAP NetWeaver Identity Management is a general purpose identity managementapplication which provides the functions and services needed to integrate distributed identity

    data in the system landscape to efficient, heterogeneous identity lifecycle management.

    The reader

    This manual is written for people who are to transport configurations between systemenvironments, e.g. test/QA environment to production environment.

    Prerequisites

    To get the most benefit from this manual, you should have the following knowledge andsoftware:

    Thorough understanding of the SAP NetWeaver Identity Management.

    SAP NetWeaver Identity Management 7.2 SP5 or newer is correctly installed and licensed.

    The manual

    The manual describes the issues that need to be considered when implementing an IdentityCenter configuration that should be prepared for a transport. You also find information about

    the necessary preparations and transport process.

    This tutorial is not a substitution for training.

    Related documents

    You can find useful information in the following documents:

    SAP NetWeaver Identity Management Identity Center tutorials and help file

    SAP NetWeaver Identity Management Solution Operation Guide

    SAP NetWeaver Identity Management Security Guide

    SAP NetWeaver Identity Management Identity Center Implementation guide Staging

    environment

    SAP NetWeaver Identity Management Migration guide Identity Management 7.1 to 7.2

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    4/40

    ii

    Copyright 2012 SAP AG. All rights reserved.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    5/40

    iii

    Copyright 2012 SAP AG. All rights reserved.

    Table of contents

    Introduction .................................................................................................................................. 1

    The development environment and process ........................................................................................... 1

    Upgrading from SAP NetWeaver Identity Management 7.1 .................................................................. 4

    Section overview .................................................................................................................................. 5

    Section 1: Implementation considerations (Identity Center)....................................................... 6

    Repository definitions and job executions ............................................................................................. 6

    GUIDs .................................................................................................................................................. 7

    Global constants ................................................................................................................................... 8

    Global variables and job variables ......................................................................................................... 8

    Parameterized constants that contain passwords .................................................................................... 8

    Encrypted attributes .............................................................................................................................. 9

    Identity store references ........................................................................................................................ 9

    References to identity store entries ...................................................................................................... 10

    Attributes ............................................................................................................................................ 10

    Entry types ......................................................................................................................................... 11

    Tasks .................................................................................................................................................. 11

    Filters ................................................................................................................................................. 11

    Audit flags .......................................................................................................................................... 12

    Job scripts ........................................................................................................................................... 12

    Global scripts ...................................................................................................................................... 12

    Event agents ....................................................................................................................................... 12

    Dispatchers ......................................................................................................................................... 12

    Templates for notification messages .................................................................................................... 13

    Summary ............................................................................................................................................ 13

    Section 2: Implementation considerations (Virtual Directory Server) ..................................... 15

    References to external systems ............................................................................................................ 15

    Section 3: Preparing for transport ............................................................................................. 16

    Permissions ........................................................................................................................................ 16

    Preparing the Virtual Directory Server transport (optional) .................................................................. 17

    Creating repository constants of type job reference.............................................................................. 18

    Preparing the target system ................................................................................................................. 18

    Section 4: Performing a transport .............................................................................................. 20

    Exporting the configuration from the source system ............................................................................ 20

    Importing the configuration to the target system .................................................................................. 21

    Section 5: Post-transport tasks ................................................................................................... 22

    Post-transport configuration tasks (Identity Center) ............................................................................. 22

    More information ................................................................................................................................ 23

    Post-transport tasks (Virtual Directory Server) .................................................................................... 24

    Handling removed tasks ...................................................................................................................... 27

    Section 6: Copying a repository definition ................................................................................. 29

    Appendix A: Differences between Configuration Copy Tool and transport ............................ 30

    Appendix B: Removing identity stores from the target system ................................................. 34

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    6/40

    iv

    Copyright 2012 SAP AG. All rights reserved.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    7/40

    1

    Introduction

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Introduction

    The SAP NetWeaver Identity Management is often used in business critical operations. To beable to test and add new functionality, as well as software upgrades, it is important to have both

    a development and a test/QA (quality assurance) environment, which is similar to, but separatefrom the production environment. This separation of development, test and production

    environments is referred to as staging.

    In the development and test environments new functionality and configurations are created andverified, without the danger of disrupting the ongoing production. Once the solution is ready thecopy of the corresponding configuration, either a complete configuration or just a part of it, is

    moved to the test environment(s) (using the Configuration Copy Tool (Export/Import) ortransport) from the Identity Center Management Console. After thorough testing and

    verification in the test environment(s), the copy of the complete configuration can be moved tothe production environment using the transport.

    The development environment and process

    Developing and expanding a system in production may be quite demanding. The goal is tointroduce new customizations, features or applications with as little downtime as possible.Traditionally, the development is an at least three tier structured process (and often four tier),maximizing the productivity and reducing risks and bugs that reach the user. Especially those

    having complex and large production systems, need to make sure that newcustomizations/features/applications are thoroughly tested before they are rolled out to the

    production environment.

    The more complex the system is, the more reason there is to be protective and proactive aboutit. We recommend using the four tier structure:

    Development:

    This is the working environment for individual developers or small teams. This way,working in isolation with the rest of the tiers, the developer(s) can apply radical changes tothe application(s) without adversely affecting the rest of the development team(s). It isimportant to coordinate the use (i.e. naming and semantics of usage) of the followingresources, which are always included in a transport:

    Global scripts.

    Global constants: No global constants, except of the job or task references, are

    overwritten when transporting or importing configuration. Global constants are alwayscreated if they do not already exist.

    Repository definitions (no repository definition constants, except of the job or task

    references, are overwritten when transporting or importing configuration). Typically,you will have one repository definition of each type in test environments (QA and/orintegration). In production, there will be one for each real repository in the landscape.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    8/40

    2

    Introduction

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Integration:A common environment where all developers commit changes from the development

    environment. The goal of this environment is to integrate and validate the work of the entireproject team (and often even several project teams that are working in parallel), so it can betested before being promoted to the next stage in the process. Development and integration

    testing can be performed in the same environment, i.e. having a dedicated environment forintegration testing is optional although recommended.

    QA:The QA tier is an environment that is, and should be, as identical to the productionenvironment as possible. The purpose of this environment is to simulate as much of the

    production environment as possible. The QA environment will also work perfectly as ademonstration and/or training environment.

    Production:The working system.

    These are environments, and not single or dedicated servers. The tiers may co-exist on the same

    physical server. The exception is the production environment, which should not be shared withthe other environments.

    While the integration and development environments can have only a limited subset of data, theQA environment should have the identical software configuration as the productionenvironment (except that in QA, you will not need all repository definitions but at least one ofeach type) and a complete, independent copy of the production database so it is a true basis forQA testing. It should also have comparable hardware configuration to the production system so

    an accurate forecast of capacity by performance testing against it. To verify performance, itshould also have the same (or similar) role hierarchy and a comparable number of entries as in

    the production environment.

    The developers are developing and making changes only in the development and integration

    environments, i.e. at no point should a developer make changes directly to the QA or productionenvironments.

    Moving the configuration between tiers

    The new feature/configuration is copied from the development environment to the test systemusing Configuration Copy Tool, which unlike the transport allows moving copies of only the

    parts of the configuration (i.e. the transport will move copies of the complete configurationonly). Note some challenges introduced by copying only parts of the configuration inAppendix

    A: Differences between Configuration Copy Tool and transporton page 30.

    When the integration test is completed and the developers are satisfied with the behavior of the

    integration environment, a copy of the configuration is moved to the QA environment using theConfiguration Copy Tool. If both tasks and jobs are to be copied to QA, this must be done inseveral operations.

    Note:It is possible to use transport to move a copy of the configuration from development or

    integration environment to QA environment. The Configuration Copy Tool will give you the

    possibility of moving only parts of your configuration. If you don't need this flexibility, we

    recommend using the transport.

    At this point the quality assurance testers start their review. The QA reports go back to thedevelopers who fix them. After all of the bugs are fixed, a new version is provided to QA

    (developers should only make changes in the development and integration environments). Thisprocess continues until the QA team declares the QA version to be ready for release.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    9/40

    3

    Introduction

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    When a version of the configuration is ready to be released to the production environment, the

    copy of the configuration is moved using the transport which will copy the completeconfiguration.

    To perform the transport, the configuration is exported from the source environment. The

    resulting file(s) must be transferred to the target environment (imported).

    An import to the target system is done within a transaction. If something fails, the transaction isrolled back, and nothing is changed. There are two cases which will make the transport to fail(abort):

    The identity store on the target system is not empty (i.e. it contains tasks) when the transportis performed for the first time.

    An identity store is removed from the source system, the transport file of this configurationcreated (exported) and then transported to the target system. The transport will abort, sinceit is not allowed to remove the identity stores from the target system. Unnecessary (excess)identity stores in the target system must be removed manually. For more information see

    Appendix B: Removing identity stores from the target systemon page 34.

    The purpose of the transport is to ensure that the configuration in the production environment isas identical as the configuration that was tested in the QA environment as possible, i.e. ourrecommendation is that the production system should be as an exact copy of the QA system aspossible. As already mentioned, the only difference between the systems in the two

    environments is a number of repository definitions, a set of configuration parameters in the

    repository definitions (typically connection information), and entries. In addition, there may beselected global constants that have different values.

    In order for the transport to work, it is required that identity store(s) with the same GUID(s) asin the source system exist(s) in the target system. To achieve this, the first time the transport is

    performed (and only this first time, i.e. during the initial transport) the existing identity store inthe target system, the one where you previously created the administrator user, is overwrittenwith the identity store from the source system (giving the same GUID in source and targetsystems). The identity store in the target system will be overwritten only if it is empty (containsno tasks). All the other times the transport is performed the identity stores will either be updated

    if they already exist, or be created if they don't. Multiple identity stores are created on the targetsystem by transport if the transport file (and thus the source system) contains more than one

    identity store. The GUIDs will be the same in both source and target systems.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    10/40

    4

    Introduction

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Upgrading from SAP NetWeaver Identity

    Management 7.1

    When you have upgraded a configuration from SAP NetWeaver Identity Management 7.1 to

    SAP NetWeaver Identity Management 7.2 according to document SAP NetWeaver IdentityManagement Migration guide Identity Management 7.1 to 7.2, the configuration is normallycopied with the Configuration Copy Tool according to the process described in the documentSAP NetWeaver Identity Management Identity Center Implementation guide Staging

    environment.

    After upgrading to SAP NetWeaver Identity Management 7.2, it is recommended to begin usingthe transport which has the following benefits:

    Unlike the Configuration Copy Tool that allows copying of only parts of the configuration,the transport copies the complete configuration. Doing this you will avoid the challenges

    and issues described inAppendix A: Differences between Configuration Copy Tool andtransporton page 30.

    Using transport it is ensured that the configuration running in production is as similar to thesystem which was tested in QA environment as possible.

    All transports are logged, giving a history of changes in the production system (doing

    changes directly in the production system will not be logged, and should be avoided).

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    11/40

    5

    Introduction

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Section overview

    The document consists of the following sections:

    Section 1: Implementation considerations

    Identity Center

    This section gives an overview of issues that

    should be considered when implementing asolution that is to be transported between systemenvironments.

    Section 2: Implementation considerationsVirtual Directory Server

    This section gives an overview of issues thatshould be considered when designing aconfiguration in the Virtual Directory Server thatis to be transported.

    Section 3: Preparing for transport This section describes the necessary steps toprepare the target system(s), as well as thepermissions needed when performing aconfiguration transport.

    Section 4: Performing a transport Here you find a task list that must be done in thetest and production environments to performtransport.

    Section 5: Post-transport tasks After configuration transport a few post-transportoperations should be performed in the targetsystem(s). This section gives an overview ofthese tasks.

    Section 6: Copying a repository definition This section gives an overview of how to copyrepository definitions and the job referencesusing the SAP NetWeaver Identity Management

    Administration User Interface.

    Appendix A: Differences betweenConfiguration Copy Tool and transport

    The section describes the differences between theConfiguration Copy Tool (Export/Import) andtransport. Use cases/examples are described.

    Appendix B: Removing identity stores from

    the target system

    The special case of removing identity stores from

    the target system is addressed in this section.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    12/40

    6

    Section 1: Implementation considerations (Identity Center)

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Section 1: Implementation considerations (Identity Center)

    When you implement a solution in either the Identity Center or the Virtual Directory Server,there are some issues that should be considered and implemented in a specific way for this to be

    done as smoothly as possible.This section describes issues that must be considered when implementing a solution that is to betransported between system environments. Any new features or versions are introduced in thedevelopment environment before they are transferred to the test and production environments.

    When exporting a configuration for transport, the contents of the Identity Center database are

    exported, including all identity stores, attributes, and groups.

    This means that the target system will have an identical configuration as the source system.

    The main challenge for proper handling of configuration updates are references between objectsin the configuration. To be able to handle this properly, there are several issues you need to beaware of. These are discussed in the following subsections.

    Repository definitions and job executions

    In the QA system there must be at least one repository definition of each type. Normally, thereis a need of having many repository definitions of the same type in the target production system.Using the SAP NetWeaver Identity Management Administration User Interface you are able to

    copy an existing repository definition. This will make an exact copy of an existing repositorydefinition, but with a new name. You will then have to manually fix any connection specificconstants.

    When copying a repository definition, any job references will also be copied, i.e. the same job

    definition may be referenced from several repository definitions. This is done by creating a newrepository definition for the given job. This way, there is no need to create new jobs for each

    copy of the repository definition. The job itself is not duplicated, only the references to newrepository definitions are created automatically. In other words, the same job is shared betweenand executed for all new repository definitions. The SAP NetWeaver Identity ManagementAdministration User Interface provides functionality for executing a job for a repository

    definition (for example an initial job or a reconcile job). This job will then run for the givenrepository definition.

    In order for this to work, the references need to point both ways, i.e. both from repositorydefinition(s) to the job, and from the job to repository definition(s). See more information inSection 3: Preparing for transporton page 16 and the subsection Creating repository constantsof type job referenceon page 18.

    Read more about copying of repository definitions in Section 6: Copying a repository definition

    on page 29. You may also find more information in Help File (section Configuring job options(Identity Center)).

    In the next two subsections, more details about repository and job definitions are described.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    13/40

    7

    Section 1: Implementation considerations (Identity Center)

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Repository definitions

    When exporting a configuration for transport, all repository definitions will always be exported.

    When importing a configuration to the target system, the existing repository constants are neveroverwritten and only created if they do not exist (the exception is task and job references which

    will be overwritten when using Configuration Copy Tool and transport). The reasoning behindthis is that the repository definitions often will reference local resources, which are different in

    the source and target environments. This also means that you will have to change the connectionspecific constants only once in the production system for a given repository. Repositorydefinitions can be changed using the SAP NetWeaver Identity Management AdministrationUser Interface. See sectionAdjusting system parameters in the target systemon page 22 formore.

    In the QA system there must be at least one repository definition of each type. The repository

    definition names transported to the production environment are the same as in the testenvironment. With this in mind, the naming of the repository definitions should be generic, as

    the name will be reused in production. So, in order to work across the environments it is

    recommended that the local resource a repository definition is referencing is not reflected in thename of the repository definition.

    Repository variables are not transported.

    All task references should be defined on the repository definitions and not on the roles and

    privileges.

    When performing updates in the source system, you must consider if there are repositoryconstants which must be updated manually in the target system after import.

    Job definitions

    When importing, make sure that the imported jobs are enabled and have a default dispatcherdefined in the target system. This can be defined in the Identity Center Management Console in

    the target system (the "Options" tab in the details pane of the Identity Center entry in theconsole tree).

    GUIDs

    The key objects within the Identity Center configuration are identified using a GUID (Global

    Unique Identifier). This identifier is generated when the object is created in the Identity Centerdatabase, and guarantees uniqueness of the object across systems.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    14/40

    8

    Section 1: Implementation considerations (Identity Center)

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Global constants

    When exporting a configuration for transport, all the global constants will always be exported.

    When importing a configuration to the target system, existing global constants are never

    overwritten, only created if they do not exist. The reasoning behind this is that the globalconstants will often reference local resources, which are different in the source and targetenvironments. A couple of examples would be the reference to an SMTP server and originatorfor sending e-mails.

    The exception is task and job references which will be overwritten when copied using both

    Configuration Copy Tool and transport. These will point to some task or job to perform anoperation, and are considered a part of the configuration, and are therefore overwritten whenusing Configuration Copy Tool and transport.

    When updating global constants in the source system, you must consider if there are globalconstants which must be updated manually in the target system after import. You need tochange them only once in the production system. Global constants can be changed using the

    SAP NetWeaver Identity Management Administration User Interface. See sectionAdjustingsystem parameters in the target systemon page 22 for more.

    Global variables and job variables

    Neither global variables nor job variables are exported. They are only referenced from scripts,

    and the script itself must take care of creating the variables as needed.

    Parameterized constants that contain passwords

    For global or repository constants that are parameterized and contain passwords, for example,JDBC URLs, we recommend setting the password in a global or a repository constant andreferencing this constant in the parameterized URL. In this way, the value for the constant can

    be changed in the system parameters in the production system (in the "Transport" tab of theIdentity Management Administration User Interface).

    To follow this recommendation (when creating a parameterized constant in the source system

    using the Identity Center Management Console) first create the global/repository constant of thetypepassword. Then create the constant for the parameterized constant, e.g. one of type JDBCURL. Going through the wizard, don't enter the password directly in the input field for thepassword, but use the context menu to select the password constant you have created before.

    The complete URL will then look like the following example for a JDBC URL:

    j dbc: sql ser ver : / / host : 1433; databasename=dbname; user name=user; passwor d=%$gl b. TEST_PWD%

    Having transported a configuration with such constants, select the password constant to change

    the password and select the parameterized constant to change all other parameters of it. SeesectionAdjusting system parameters in the target systemon page 22 for more.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    15/40

    9

    Section 1: Implementation considerations (Identity Center)

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Encrypted attributes

    Attributes that are stored encrypted in the development or test system are transported encrypted.Therefore, to be able to decrypt these values in the production system, you must distribute theKeys.inifile to the production system.

    It is recommended to have/assign specific encryption key ranges for each environment a rangeof keys for the production system that is not available in the development/QA system, forinstance all keys above 100 are reserved for the production system.

    Note:The encrypted attributes that are transported, are re-encrypted (with the new encryption key)

    first after they have been edited and stored in the target system.

    For more information about encryption keys, see the document SAP NetWeaver IdentityManagement Security Guide.

    Identity store references

    The identity store is referenced from all "To Identity store"-passes, as well as To-passes whichuse the identity store as source. If an identity store is selected from the drop down, this is stored

    as a numeric value, but will be converted to the GUID of the identity store when exporting. Thiswill be re-mapped on import to the target system.

    As an alternative you can use a global constant to reference the ID of the identity store. You can

    then use this global constant in the drop-downs for the identity store (note that it is not possibleto use the context menu to insert values in a drop-down text box, you will have to type them inmanually or use cut/paste).

    The definition of the global constant would be like this:

    The global constant is used in the following way in a To-pass:

    Finally it is possible to use the reference "-- Self --" in passes which run as action tasks. Thisindicates the use of the identity store where the task is executing.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    16/40

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    17/40

    11

    Section 1: Implementation considerations (Identity Center)

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Entry types

    When exporting a configuration for transport, the entry type definitions are also exported.

    When importing to the target system, non-existing entry types are created. Modified entry types

    are updated, with exceptions/restrictions as described in the next subsection.

    Entry type restrictions

    If the change to the entry type may cause problems with data in the identity store, the update isnotperformed, and a warning is given. This includes the following:

    If attributes have been removedin the source environment, these are notremoved in thetarget environment, as this may result in values being removed from the identity store, as

    they are no longer allowed on the entry type.

    If an attribute is set to mandatory, which was not mandatory before, this is not set to

    mandatory, as there might be entries within the identity store which does nothave thisattribute, and this would violate the new setting.

    Tasks

    When exporting a configuration for transport, the task hierarchy is exported, including all tasksand jobs.

    All entries used in access control will also be exported (referred with their MSKEYVALUE).

    When transporting, these entries will be created on import if they do not exist (i.e. they are notupdated if they already exist), and reconnected to the access control on the task. The entries are

    not transported with all of their attributes only MSKEYVALUE and links (but not the actualentries that the links are referencing to) are transported.

    Any access control involving a filter may cause problems. For details about filters, see the nextsection Filters.

    For information about removing tasks from a task structure, see page 27.

    Filters

    Any use of filters may cause problems. The filter can be used as the access control on tasks, andas source in a To-pass.

    If the filter is created using the wizard it should normally work OK, but if any modifications aremade to the filter, there is a risk that it will not work properly in the target environment.

    References like "is_id", "ocisid" or "mcidstore", which are identity store references, exist withinthe filters, e.g.:

    SELECT DI STI NCT mskey FROM i dmv_val l i nk_basi c_act i ve WHERE mci dst or e=1 AND( ( mskey I N ( SELECT mcmskey FROM i dmv_val l i nk_basi c_act i ve WHEREmcat t r name=' MX_ADDRESS_CI TY' AND mcsear chval ue = ' TRONDHEI M' ) )AND (mcmskey I N ( SELECT mcmskey FROM i dmv_val l i nk_basi c_act i ve WHEREmcat t r name=' MX_TI TLE' AND mcsearchval ue = ' MANAGER' ) ) )

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    18/40

    12

    Section 1: Implementation considerations (Identity Center)

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    The export process will try to locate any such identity store references within the filter. The

    value following the "=" will be replaced with the GUID of the given identity store upon export,and reconnected with the correct identity store (if it exists) when updating the targetenvironment.

    If custom specific filters are required, it is possible to use global constants as part of the query.

    Audit flags

    All audit flags will be exported.

    When transporting, audit flags will not be overwritten on import to target system, but onlycreated if they do not exist (i.e. they are not updated if they already exist).

    Job scripts

    Local job scripts will always be overwritten in the target environment (which also means thatthe scripts that have been deleted in the source system will be removed from the target systemas well).

    If a script needs references to for example tasks or other identifiers which may be changedduring the transport, global constants should be used for this.

    Global scripts

    Global scripts are always overwritten (which also means that the scripts that have been deleted

    in the source system will be removed from the target system as well).Internal references should be done using global constants.

    Event agents

    Event agent definitions are nothandled by the transport, and must be set manually in the targetenvironment (using the SAP NetWeaver Identity Center Management Console) after the first

    import.

    When updating the target environment, the event agent definitions are not changed.

    Dispatchers

    Before performing the first import when transporting, the dispatcher(s) should be created in thetarget environment (using the Identity Center Management Console) with the same name as inthe source environment. The transport does not handle the dispatcher definitions, but will linkany jobs imported in the target environment to the dispatcher(s) with the same name as in thesource environment.

    If no matching dispatcher(s) are found, it will use the dispatcher which is defined as default.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    19/40

    13

    Section 1: Implementation considerations (Identity Center)

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Templates for notification messages

    Templates for notification messages (see SAP NetWeaver Identity Management SolutionOperation Guide, section 5.9 Maintaining message templates) are exported.

    During import to a target system, only new message templates are imported. Existing messagetemplates are never overwritten. If you have done changes to the message templates in thesource system that you want to import to the target system, the corresponding messagetemplates can be deleted from the target system before the import. Otherwise the same changes

    must be done also in the target system.

    Summary

    The following is a list you should be aware of during the update process.

    Repository and job

    definitions

    Make sure that these are enabled and have a default dispatcher

    defined when imported to target system.

    Repository definitions and the job references can be copied in theproduction environment using the SAP NetWeaver Identity

    Management Administration User Interface.

    Global constants Will be created only if they don't exist, never overwritten (updated) inthe target environment if they already exist. The exception is task andjob references which will be overwritten when copied using bothConfiguration Copy Tool and transport.

    Global variables Are not transported.

    Job variables Are not transported.

    Repository constants Will be created only if they don't exist, never overwritten (updated) inthe target environment if they already exist. The exception is task andjob references which will be overwritten when copied using bothConfiguration Copy Tool and transport.

    Parameterizedconstants that containpasswords

    If a parameterized constant contains a password parameter, create anencrypted global or repository constant that contains the value.Reference the password constant in the parameter value of the URLconstant.

    Encrypted attributes Transported encrypted. Distribute the Keys.inifile to the targetsystem.

    Identity storereferences

    In some cases, identity store references may not be handled properly.

    Attributes If changes to the attributes put more restrictions on entries in theidentity store, then these updates will notbe done, and a warning will

    be given on import.

    Attribute values queries and scripts may not be handled properly.

    Entry types If changes to the entry type put more restrictions on entries in theidentity store, then these updates will not be done, and a warning willbe given on update.

    Be careful when using filters in access control, as they may not be

    handled properly.

    Tasks Conditional tasks, see Filters. Other tasks are OK.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    20/40

    14

    Section 1: Implementation considerations (Identity Center)

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Filters In general, filters may cause problems during the transport.

    Audit flags Audit flags will be created only if they don't exist, never overwritten

    (updated) in the target environment if they already exist.

    Job scripts References to task numbers, job numbers or other local objects.

    Always overwritten in the target environment (which also means thatthe scripts that have been deleted in the source system will beremoved from the target system as well)

    Global scripts Same as job scripts.

    Event agents Are not transported.

    Dispatchers Dispatchers themselves are not transported, but only dispatcherassignments e.g. from jobs. Be sure to create dispatchers with thesame name in the production environment.

    Message templates Will be created only if they don't exist. They are never overwritten(updated) in the target environment if they already exist. To update

    the message templates from the source system, the existing templatesmust be deleted from the target system before they are transported.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    21/40

    15

    Section 2: Implementation considerations (Virtual Directory Server)

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Section 2: Implementation considerations (Virtual Directory

    Server)

    When developing a configuration in the Virtual Directory Server, you need to consider the

    following issues to prevent issues when transporting the configuration to another environment.

    References to external systems

    In a transport, references to external systems normally must be updated to reflect the

    environment in the target system.

    To ensure that this can be done as efficient as possible, all such details should be created asglobal constants in the Virtual Directory Server. All constants will be transported to the target

    system, and you can modify them using the Identity Management Administration UserInterface. See page 22 for details.

    The following Virtual Directory Server configuration information includes references toexternal systems:

    Data source definitions

    Deployment configurations

    Client credentials (user properties)

    Keystore definitions (keystore definitions are not transported, although they can be createdand managed in the Virtual Directory Server)

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    22/40

    16

    Section 3: Preparing for transport

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Section 3: Preparing for transport

    Before a transport can be performed, the following steps must be completed:

    Permissions for performing the transport and configuration modifying.

    Prepare the Virtual Directory Server configuration for transport (optional)

    For new repository definitions, link all related jobs to the repository definitions usingrepository constants of type "job reference. This applies to all jobs you need to run in thetarget system.

    Usually, you need to run the initial load job for the repository definition in the targetsystem. Therefore, you create a job reference constant in the repository definition and selectthe corresponding initial load job as the constant value.

    Prepare the target system

    Permissions

    The permissions used for transporting and modifying configurations are set up using thefollowing privileges:

    MX_PRIV:CONFIG_AUDIT: This permission allows a user to view the history of changes

    made to the configuration (in the "Configuration History" tab).

    MX_PRIV:CONFIG_R: A user with this privilege is only allowed to view global and

    repository constants (repository definitions) in the "System Parameters" tab.

    MX_PRIV:CONFIG_RW: A user with this privilege is allowed to modify global and

    repository constants (repository definitions) in the "System Parameters" tab. MX_PRIV:TRANSPORT:EXPORT: This permission allows a user to export a

    configuration (in the "Transport" tab).

    MX_PRIV:TRANSPORT:IMPORT: This permission allows a user to import a

    configuration (in the "Transport" tab).

    Make sure the users performing the transports and making the adjustments have the appropriatepermissions (in both source and target system). If a user does not have any appropriate

    permission for a tab, the tab is not displayed.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    23/40

    17

    Section 3: Preparing for transport

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Preparing the Virtual Directory Server transport

    (optional)

    To include the Virtual Directory Server configuration in the transport, the configuration must be

    uploaded to an Identity Center database that is transported from the source system. Onceuploaded the Virtual Directory Server configuration will appear as a repository definition in theIdentity Center Management Console. Before you can upload a configuration for transport, youmust do the following in the source system:

    1. Make sure that the JDBC driver for the Identity Center database is included in the classpath,i.e. choose Tools/Optionsin the Virtual Directory Server console, select the "Classpath"tab and then make sure that the classpath is defined.

    2. For each configuration, configure the transport options. This needs to be done only once for

    each configuration. The information provided here is used when connecting to the IdentityCenter database where the configuration is to be uploaded. To do so, selectTransport/Options in the Virtual Directory Server console. This opens a "Transport

    options" dialog box:

    Fill in the following:

    Identity Center URL:

    Enter the JDBC URL to the Identity Center database where you want to upload theconfiguration. Choose "" to the right of the field to open the JDBC URL wizard whereyou can specify the connection details to the Identity Center database. Use the

    _admin user to connect to the database.

    JDBC Driver class:

    This field displays the JDBC driver that is used to connect to the Identity Center database.The field is filled out automatically when the Identity Center URL has been specified (i.e.no need to fill this field in manually).

    Unique ID:Enter a unique ID for the configuration. This will be used as the repository definition name

    that will contain the global constants from the configuration in the Identity Center. Make

    sure that this unique ID is unique for all configurations that will be stored in the sameIdentity Center database. The unique ID is prefixed with "MXVDS_" in the Identity Center.

    3. Choose "OK" to save and close the dialog box.

    4. Select Transport/Uploadand then choose "Yes" to upload the Virtual Directory Server

    configuration to the Identity Center database. This needs to be done each time you want theconfiguration to be included in the transport and each time the configuration has been

    changed.

    Note:

    Before a configuration can be uploaded, it must have been started once, as it is the version

    in the work area that is uploaded to the Identity Center.

    5. A configuration upload success/failure status dialog box appears. Choose "OK" to close.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    24/40

    18

    Section 3: Preparing for transport

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Now the uploaded Virtual Directory Server configuration is ready for transport, with all global

    constants added to the repository definition named MXVDS_

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    25/40

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    26/40

    20

    Section 4: Performing a transport

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Section 4: Performing a transport

    This section describes how to transport a configuration from a source to a target environment. Itis assumed that you have a thorough knowledge of the Virtual Directory Server and the Identity

    Center, i.e. to perform transport a high knowledge of the SAP NetWeaver Identity Managementis required. For details, see the relevant tutorials or help file for the product.

    It is always a complete Identity Center configuration (including all the Virtual Directory Serverconfigurations that have been uploaded to the Identity Center) that is transported.

    The process consists of the following steps:

    Exporting the configuration from the source system.

    Importing the configuration to the target system.

    The first time the transport is performed (the initial transport) the identity store in the targetsystem will be overwritten, and only if it is empty (contains no tasks). This makes it importantto make sure that the identity store on the target system does not contain any tasks during theinitial transport. Otherwise the transport (import of the transport file to the target system) will

    fail.

    Unnecessary (excess) identity stores on the target system must be removed manually, i.e. thetransport is not allowed to remove the identity stores from the target system. See section

    Appendix B: Removing identity stores from the target systemon page 34.

    Exporting the configuration from the source system

    To export the configuration from the source system, do the following:

    1. Start the SAP NetWeaver Identity Management Administration User Interface in the sourcesystem, http://:/idm/admin.

    2. Select the "Transport" tab.

    3. Select the "Export Configuration" option in the menu to the left:

    Enter a reason for the export.

    Note:

    Include a system description, for the system you are exporting from. This helps when

    identifying the imported file in the target system.

    4. Choose "Generate Export File" to export the configuration.

    The configuration is now exported for transport and available for download as an XML file. Todownload the file, choose the "Download Last Configuration Export (as XML)" link and savethe file to your local file system.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    27/40

    21

    Section 4: Performing a transport

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Importing the configuration to the target system

    Before importing the configuration to the target system, make sure that the following isperformed:

    The configuration has been exported from the source system and exists as an XML file inthe file system.

    Dispatchers are not running in the target system.

    The identity store is empty (contains no tasks).

    To perform import to the target system, do the following:

    1. Start the SAP NetWeaver Identity Management Administration User Interface in the target

    system, http://:/idm/admin.

    2. Select the "Transport" tab and then "ImportConfiguration" option from the menu on theleft:

    Choose "Browse" to the right of the "Select New Configuration File" field to select theconfiguration file from the file system.

    3. Choose "Upload".4. To verify the correctness of the configuration file, choose "Check". If the check returns

    errors, correct these in the source system and export the configuration file again before

    proceeding.

    5. To import the configuration file, choose "Import".

    The configuration file is now imported. The changes that took place during the import aredisplayed in theLog Entriesin the lower section of the screen.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    28/40

    22

    Section 5: Post-transport tasks

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Section 5: Post-transport tasks

    After the configuration is successfully transported to the target system, some post-transportoperations should be performed.

    Post-transport configuration tasks, performed in the Identity Center (Management Console) andthe SAP NetWeaver Identity Management Administration User Interface, like:

    Linking event agent references

    Adjusting system parameters (global and repository constants) in the target system

    Updating task references on privileges

    Assigning new encryption keys and re-encrypting constants

    apply to the whole (compound) configuration, composed of both the Identity Center and theVirtual Directory Server configuration.

    Section Post-transport tasks for Virtual Directory Serverdescribes the post-transport actions

    specific for the Virtual Directory Server configuration, like:

    Extracting and running the Virtual Directory Server configuration

    Deploying the Virtual Directory Server configuration

    Tasks removed from the configuration in the source system need special handling whenupdating the target environment (performing transport). SectionHandling removed tasksdescribes how.

    Avoid using the Identity Center Management Console in the production system after the firstsuccessfully performed transport of the configuration (after successfully completing the

    transport and the post-transport tasks). The exception is when removing an identity store from

    the target system (see sectionAppendix B: Removing identity stores from the target systemonpage 34).

    Post-transport configuration tasks (Identity Center)

    This section describes the post-transport tasks performed on the configuration in the IdentityCenter (Management Console) and the SAP NetWeaver Identity Management AdministrationUser Interface.

    Linking event agent references

    After importing the configuration, set the event agent job references to the corresponding jobsthat you imported in the Identity Center Management Console. For more information, see theonline help for event agents.

    Adjusting system parameters in the target system

    Once you have imported the configuration, with new global constants and/or new repositorydefinitions, you may need to make some changes to system parameters, for example servernames or user IDs that are used for various connections. You can make changes to global or

    repository constants.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    29/40

    23

    Section 5: Post-transport tasks

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Note:You can onlychangethe constants in the SAP NetWeaver Identity Management Administration

    User Interface. To create global constants or add repository definitions to the system, create

    them in the development or test system using the Management Console and test thoroughly

    before transporting them to the target/production system.

    1. To make changes to the system parameters, choose the "System Parameters" tab from the

    Identity Management Administration User Interface.

    2. Select option "Global Constants" or "Repositories" to change the corresponding constants.Change the constant values directly in the corresponding table.

    Note:

    You can change the parameters for parameterized constants such as JDBC URLs by

    selecting the constant value. The parameters for these constants are then displayed

    separately and can be changed.

    Note:If a parameterized constant contains a password parameter that is encrypted, create an

    encrypted global or repository constant that contains the value. Reference the password

    constant in the parameter value of the URL constant. This ensures that the password is

    encrypted and can be changed.

    3. Save the data.

    Updating task references on privileges

    All task references should be defined on the repository definitions and noton the roles andprivileges. If, by any chance, any task references exist on roles/privileges, make sure tomanually set the task references to the appropriate tasks that were imported (e.g. in the IdentityCenter Management Console, or by creating a User Interface task which performs the updates).

    For more information, see the online help for configuring task references on privileges.

    Assigning a new encryption key and re-encrypting constants

    If you are transporting constants that are encrypted, the target system must have access to thesame encryption key that was used for encrypting the constants in the source system. Because

    these keys are known outside of the target production system, we recommend creating a newkey to use for encryption in the target system and re-encrypting such constants after transports

    (that contain encrypted constants). To re-encrypt, edit the affected constants in the "SystemParameters" tab of the Identity Management Administration User Interface and save.

    For more information about how to create a new encryption key, see the document SAPNetWeaver Identity Management Security Guide.

    More information

    All transports are logged, giving a history of changes in the production system. Doing changes

    directly in the production system will not be logged, and should be avoided. You can view ahistory of configuration changes, including the date, time, responsible user and reason ofimports and exports in the "Configuration History" tab of the Identity ManagementAdministration User Interface. For imports, even the complete imported configuration files areavailable. For more information, see the document SAP NetWeaver Identity Management

    Solution Operation Guide.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    30/40

    24

    Section 5: Post-transport tasks

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Post-transport tasks (Virtual Directory Server)

    This section describes the Virtual Directory Server specific post-transport tasks.

    Extracting and running the Virtual Directory Server configuration

    After the transport is performed and the configuration (including the Virtual Directory Serverconfiguration) is transported to the target system with the Identity Management AdministrationUser Interface, the Virtual Directory Server configuration must be extracted from the IdentityCenter database and stored in the file system of the target system. This is done with the

    Configuration Extractor.

    The Configuration Extractor is included with the installation of the Virtual Directory Server andis available in the directory \transport. It is a Java program that must bestarted in the target system, i.e. in the system where the transported Virtual Directory Serverconfiguration is to run.

    For successful execution, the Configuration Extractor requires startup files that have to begenerated in the source system and manually moved to the target system. To create the startupfiles, do the following:

    1. In the Virtual Directory Server console, choose Transport/Generate ConfigurationExtractor script files.

    The files vdsext.bat and vdsext.share created and placed in the directory \transport(i.e. \transport\vdsext.batand\transport\vdsext.sh).

    Note:

    In a UNIX system, the file directories will be /transport/vdsext.bat

    and /transport/vdsext.sh.

    2. Copy the contents of the directory \transport(the generated files

    and the Configuration Extractor itself) from the source to an arbitrary directory in the targetsystem (e.g. C:\transport).

    3. The two files (vdsext.batandvdsext.sh) must be modified to adapt the connection details ofthe target system. Modify the following information:

    Note:

    If the target production system maintains the same install directory as the development/test

    system, then only the JDBC URL needs to be modified in the file.

    Path to Keys.ini file:

    Make sure that the classpath to the Keys.inifile is correct. If required, make sure that theKeys.inifile is available in the target system.

    Classpath to JDBC driver:Make sure that the classpath to the JDBC driver needed to access the database is correct.

    JDBC driver class:

    Make sure that the JDBC driver class specified is correct.

    JDBC URL:Enter the correct JDBC URL. The script files are created with the _adminuser and the corresponding password. The Configuration Extractor runs using the

    _rt user (and this user's corresponding password).

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    31/40

    25

    Section 5: Post-transport tasks

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    The JDBC URL can be copied from a dispatcher script of the running dispatcher, or from

    the "Database" tab in the details pane of the Identity Center node (in the console tree) in theIdentity Center Management Console. This procedure is recommended to avoid maintainingthe password of the database user in clear text in the script file(s).

    Path to VDS home directory:Make sure that the path is correct.

    Classpath to BootStrapVDS,jar:Make sure that the classpath to the file is correct (by default\transport).

    4. Save the changes made to the files.

    Now that the startup files for the Configuration Extractor are ready, the Configuration Extractor

    itself can be executed. The Configuration Extractor is a command line based tool, responding tothe following command line:

    where the is the created and modified startup files vdsext.batand vdsext.sh,the is the unique name given the Virtual Directory Serverconfiguration during the process of preparing the Virtual Directory Server transport on page 17,

    and the (which is case-insensitive) may be one of the following:

    get:Retrieves the configuration JAR file for the configuration with the given name from thedatabase.

    extract:Extracts (unpacks) the retrieved configuration JAR file.

    run:

    Runs the extracted configuration.

    exec:Executes the configuration with the given name, i.e. does the same as the three commandsabove (retrieves, extracts and runs the configuration). This command is typically used the firsttime the configuration is run, and the command runis used after that.

    list:Lists the available configurations.

    stop:Stops the Virtual Directory Server that runs the configuration with the given name.

    test:

    As run, but outputs the command line instead of running it.

    Running the configuration

    To get the Virtual Directory Server configuration running, do the following:

    1. Navigate to the correct directory, and then enter the command line

    exec

    e.g. for the configuration with the unique name MyVDSconfig1:

    vdsext . bat exec MyVDSconf i g1

    2. Execute the command line.

    Now the configuration should be running.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    32/40

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    33/40

    27

    Section 5: Post-transport tasks

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Handling removed tasks

    Tasks removed from the configuration in the source system request special handling whenupdating the target environment. If the provisioning queue for the task to be removed is empty,the task is removed from the target system.

    If there is a queue of entries waiting to be processed, the task will be detached from its positionin the task tree and moved to a folder calledMX:Pending-Delete. This folder will not be visiblein the User Interface.

    All references to the task will be removed, except from the following:

    Task references to this task from entries in the identity store, for instanceMX_ADD_MEMBER.

    Task references from repository definitions and global constants, for instance

    MX_MODIFY.

    Note:

    Make sure to change such references manually in the target environment if necessary.

    All entries in the provisioning queue will be processed, but no new entries will be added to thequeue.

    The task will be removed with the next update of the target environment (i.e. the next transport).

    Task dependencies

    Special care must be taken when any kind of dependencies between tasks in a task tree exist. Ifyou remove a task that another task depends on, this task may not be able to process the entries

    in its queue when the other task is removed.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    34/40

    28

    Section 5: Post-transport tasks

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Some examples

    Removing a top task

    In this example, the task is deletedfrom the source environment. Whenimporting the configuration, it willnot be possible to delete the taskfrom the target system, since thereare entries in the queue.

    It will be moved to theMX:Pending-

    Deletefolder while processing the

    entries in the queue.

    The task will not be available from the User Interface, to prevent new entries from being addedto the queue. The task will also be unlinked, if the task is also linked to another task.

    Child tasks are notunlinked in this case, as the whole task including sub-tasks should be able to

    complete.

    Removing a sub-task

    In this case, one of the sub-tasks isdeleted. When importing, it willonly be necessary to unlink the task

    from all parent tasks.

    The task will be moved to theMX:Pending-Deletefolder.

    The task will continue to process thequeue for the task until it is empty.

    At the next import, it will also be detected that the task has been deleted, and if the queue isempty at this time, the task will be deleted physically.

    Ordered UI task

    Task 1 Task 2 Task 3

    Task Folder

    Test Production

    Ordered UI task

    Task 1 Task 2 Task 3

    Task Folder

    X

    Ordered UI task

    Task 1 Task 2 Task 3

    Task Folder

    Test Production

    Ordered UI task

    Task 1 Task 2 Task 3

    Task Folder

    X

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    35/40

    29

    Section 6: Copying a repository definition

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Section 6: Copying a repository definition

    With the copy function you can create a new repository definition in the production systemusing the SAP NetWeaver Identity Management Administration User Interface. The new

    repository definition has the same features and is of the same type as the original, e.g. an LDAPrepository.

    If you want to create a repository definition of a different type, you have to do so in the IdentityCenter of your development/test system and then transport the repository definition to theproduction system. This ensures that every repository type, as well as the related logic in jobsand provisioning tasks, has been verified in your test environment prior to being used in

    production.

    Prerequisites

    Your Identity Center has at least one repository.

    The jobs related to your repository definitions exist in the Identity Center.

    Repository constants of type job reference are defined for the jobs, which you want tocopy along with the repository definition.

    Copying a repository

    1. Start the SAP NetWeaver Identity Management Administration User Interfacein the

    production system, http://:/idm/admin.

    2. Select the "System Parameters" tab and then select "Repositories" in the menu to the left.

    3. To search for the repository definition you want to copy, choose the "Go" button.If you have not entered any name, a list of all repositories is displayed.

    4. Select the repository definition you want to copy from the displayed list and choose "Copy".

    5. In the dialog box that appears, enter the name and description of the new repository

    definition.

    6. Select the repository definition's "Constants" tab and adjust the constants of the newrepository definition. For example, adjust the repository definition name in theSYSTEM_PRIVILEGE constant or the host data in the APPLICATION_HOST constant of

    a repository definition representing an ABAP application server.

    7. Select the repository definition's "Jobs" tab and start the initial load job for the new

    repository definition. If necessary, start the prerequisite jobs for the initial load job inadvance (e.g. theRead Help Valuesjob for an AS ABAP system).

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    36/40

    30

    Appendix A: Differences between Configuration Copy Tool and transport

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Appendix A: Differences between Configuration Copy Tool

    and transport

    The Configuration Copy Tool, used to copy the configuration from development to test

    environments, unlike the transport allows copying only parts of a configuration.

    The configuration will normally hold a lot of references between the various objects that aretransported. Copying only parts of the configuration you will risk having a configuration whichhas references to objects which are not yet transported or which has old information, especially:

    Change of global tasks, which are used by other code.

    The imported code referencing old tasks which are not updated yet.

    The untouched code referencing updated tasks, which may have a different behavior, or

    deleted tasks.

    You need to have a clear picture of what parts of configuration you are introducing to the target

    system, and how these will affect the system. This section will discuss some of the challengesand issues when having separate development teams and when copying the configuration onlypartially.

    Two use cases are presented and discussed:

    Introducing changes to global scripts

    Changing the task structure

    The same example is used in both use cases. There are two projects Project Green and Project

    Blue. They have some separate repository definitions, global scripts and global constants fortheir own use (indicated with and ), but they also share some of these (indicated

    with ).

    The two projects have also their separate task and job folders, i.e. they are each responsible fortheir own parts of the task and job structure in the configuration. Some task and job references

    across their parts of the structure exist also.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    37/40

    31

    Appendix A: Differences between Configuration Copy Tool and transport

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Introducing changes to global scripts

    In this use case, the team Blue from the Project Blue is making some changes to the globalscripts. This also involves changes to common global scripts, which are implemented in

    agreement with the team from Project Green (which also has updated the configuration).

    At this point, team Blue has completed the development phase and they are ready to copy theirpart of configuration to integration and QA environments for testing, while the team Green isstill developing.

    Copying the team Blue configuration using the Configuration Copy Tool (which will include allglobal scripts), team Green may experience the following issues (the parts of the illustration

    marked with the shade of yellow are updated in the target system):

    Since all scripts are updated in the target system, the old green tasks will now reference newglobal scripts. The part of the configuration updated by the team will work fine.

    The same is the case for global constants and repository definitions.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    38/40

    32

    Appendix A: Differences between Configuration Copy Tool and transport

    SAP NetWeaver Identity Management Implementation guide - Transport

    Copyright 2012 SAP AG. All rights reserved.

    Changing the task and job structure

    In this use case, the team Blue is making changes to their task hierarchy:

    A task, which also is referenced by a Project Green task/job, is removed. This is done in

    agreement with the team Green, which also has updated the references. Changing the behavior of tasks, both those tasks which are referencing the Project Green

    tasks and those being referenced from Project Green tasks.

    Tasks Jobs

    Project GreenTasks Jobs

    Project Blue

    Global scripts Global constantsRepositories

    Team Blue is yet again ahead of their colleagues in team Green. They are ready to copy theirpart of configuration to integration and QA environments for testing, while the team Green isnot.

    Moving the copy of the configuration this time, the teams will face the following challenges:

    With a task removed by the team Blue, the old Project Green tasks which now point to a

    non-existing task remain in target system.

    When changing the behavior of tasks in Project Blue, old Project Green tasks referencing

    the changed tasks will still exist in target system. The changed Project Blue tasks will alsoreference old Project Green tasks. Both situations may cause problems.

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    39/40

  • 8/9/2019 SAP NetWeaver Identity Management Implementation Guide - Transport

    40/40