Downtime Announcement: Please note that SAP Community Wiki will be unavailable due to a system upgrade on Tuesday, August 11th between 7 and 11 AM CEST
Skip to end of metadata
Go to start of metadata

 

SAP Screen Personas


 

Transporting Personas Objects


SAP SCREEN PERSONAS KNOWLEDGE BASE - by Tamas Hoznek , Regina Sheynblat , Dominik Ofenloch

Purpose

Personas flavors (and all other objects: resources, themes, ...) are designed as very flexible objects. The original idea of a flavor is that it can be created and edited by business experts as well as by developers. Flavors can be created and edited in development systems as well as in productive environments. This flexibility of Personas objects is also reflected in the Personas database design. All Personas objects are stored in customizing tables. This provides various options while handling them but it also comes with some considerations which we'll explain in this article.

Overview

This article introduces you to the transport management of Personas objects. The following Personas objects can be transported using the Transport Management System:

Personas Objects are transported as Customizing Objects.

Export & Import of objects

This article describes the transportation of Personas Objects using the Transport Management System. The Transport Management System should be used if you plan to transport Personas Objects regularly from a development system to a productive (or other) system, based on the usual transport routes.

In many simple scenarios in which you just want to copy objects from one system to another, the transportation process may be complex and too time consuming. In this case we recommend you to use the Export- and Import functionality, which is available in the Personas administration tools.

As a difference to the Transport function, the Export- and Import function doesn't offer the inclusion of user- and role assignments of flavors and role assignments of themes. In addition, importing an object doesn't retain its origin information, so the imported object will inherit the target system's SID and client as its origin.


 Since all Personas Objects are stored in customizing tables (delivery class C), it is possible to transport them the usual way to the desired target systems and clients like other customizing objects.

Adding Personas Objects to Transport Requests

  1. Start transaction /PERSONAS/ADMIN and navigate to Tools → Transport Manager. You can also start transaction /PERSONAS/TRANSPORTS directly.

    When transporting flavors or themes, you have the option to include existing sharing / assignment information in the transport request. Of course this makes only sense if the same exact user names / PFCG user roles do exist in the target system like in the source.

  2. Now search for the objects you want to transport. Depending on the type(s) of the object(s) you are interested in, select the corresponding tab(s) and use the appropriate search criteria to find them, then hit 'Search'.


  3. You will see a tree of the found objects. If dependent objects exist, they will be added to this list. For example: In case a flavor uses a background image, the image resource file is added to this tree too. You can highlight individual objects, or just hit 'Select all', then click on 'Transport'.


  4. The transport selection popup will ask for a customizing transport request to assign all selected objects to.


  5. After all necessary objects are added to the transport request, it can be sent to the desired target systems and clients on the transport path, similar to other customization transports.


An alternate, Personas-specific method allows definition of the target clients in a customizing table. This is useful if there are multiple target clients in a system where Personas objects should be imported to and those usually do not change frequently.

For this, the transport should be sent to client 000 of the target system, and the desired import clients are specified in a customizing table.

To copy your personas objects from client 000 to your productive clients, you have to maintain table /PERSONAS/C_IMPC.

  1. Start transaction /PERSONAS/ADMIN and navigate to Customizing → Import Clients. Alternatively, you can also start transaction /PERSONAS/IMPCLIENTS.  
  2. Switch to edit mode and insert new entries.
  3. The table offers the following columns:
    • "Target System": System ID of the import system. You can enter here a specific SID (for example "PRD") or use an asterisk ("*") to import objects in all import systems.
    • "Target Client": Import client of the transported object. Here you can specify a concrete import client. In case you want to import your objects in all clients, you can also use an asterisk ("*")

      Be careful with wildcards. This option should be used wisely as it can result in unnecessary, time-consuming imports.

    • "Original System" and "Original Client": Optional fields which mean the system ID and client of the object's origin. In case these fields are empty, the table entry applies to all imported objects. Otherwise the object will be imported to the target system and client only if the object's original system and client matches this customizing setting.

  4. Save your changes.

    These customizing settings must be transported to (or maintained in) the intended target systems before the changes in Personas take effect.

    You should either send your transports to specific systems / clients, or use the Import Clients configuration method. Using both methods at the same time is counterproductive, causing unnecessary activities, thereby increases transport time.


Pushing objects from any client to the workbench / transport source client

In many environments, transports originate from a client that is not necessarily the same where Personas objects are created. There may be a dedicated client to maintain configuration, which is often missing the sufficient business data to run transactions. This "golden" client is not suitable for flavor development, however since it is the source for transports, Personas objects must be sent there. Personas provides an object push feature to move objects from any client to this workbench or "golden" client of the same system. Of course it is still possible to do this using the regular transport system if it allows such transports, but if this is not permitted, the push feature will help to take care of this.

Preparation:

  1. Log on to the customizing/source client where you are maintaining your Personas objects.
  2. Start transaction /PERSONAS/ADMIN and navigate to Customizing → Settings. Alternatively, you can also start transaction /PERSONAS/SETTINGS or maintain table /PERSONAS/STTNGS via SM30.
  3. Click the "Change" button.
  4. Add a new entry to the table:
    1. Name: PUSH_TO_CLIENT
    2. Value: <Target client>
  5. Save your changes.

Once this is done, the Transport Manager will offer the 'Push to Client XXX' function instead of 'Transport' in this client. You can select your objects and send them to the designated push target client:

When all necessary objects were pushed to the target client, you can use the 'Transport pushed objects' function of the Transport Manager in the push-to client to add them to a transport request:

Object versions

Flavors and templates have a versioning system, which allows storing multiple versions of the object. During the development phase, this can help reverting to an earlier state if so desired. At any time, it is possible to create a version manually. The Personas system also creates automatic versions, to prevent data loss if something unexpected happens while working on these objects. Each of these versions have their change history stored, and the more of such versions exist, the larger the associated data set is.

Once the development is complete and a flavor or template is in a state that it should be transported to another system, it makes sense to remove unnecessary historical data of the object, thereby decreasing the transport size. In some cases, this may mean a dramatic difference in transport time, especially if a lot of large objects are part of the transport request. Therefore, it is recommended to delete the unneeded, old versions and compress the change history of these objects before adding them to the transport request. It is up to the developer to decide whether there are certain versions that should be kept for eventual later development purposes. The idea is though that when a transport is sent across the landscape, it should be possible to eliminate a lot of unnecessary data, because multiple changes to the same screen element and older versions are not needed in a target system where no development takes place.

Behavior of transported objects

Please consider the following information about transported Personas objects:

As soon as a Personas object is transported, it will be locked in all target systems. For example:

  • In case a flavor gets added to a transport request in system DEV and transported to system PRD, it will be locked for editing in system PRD.
  • Editing of the flavor is only allowed in the original system (e.g. system DEV).
  • If you want to delete a transported flavor, you must add it to a transport request first. Afterwards you can delete it from DEV and transport the deletion to your PRD system.

To override this default locking mechanism, it is possible to maintain a setting in a target system using transaction /PERSONAS/SETTINGS with name ORIG_SYST_CHECK_OFF and value X. However, to keep objects consistent across the landscape, this is only intended for special situations.