Show TOC

Function documentationSettings for Back-End Service SAP_PD

 

You use this function to configure the SAP_PD back-end service for your form scenario. The SAP_PD back-end service enables Organization Management infotypes to be created, changed, and deleted in a form scenario. The SAP_PD back-end service is designed to deal with only object types O (Org. Unit), S (Position), and C (Job). The standard back-end services SAP_PA and SAP_PT enable the customer to create processes that update master data related to an employee by updating PA (Personnel Administration) and PT (Personnel Time Management) infotypes. A standard back-end service to update PD (Personnel Development) infotypes is now available. The framework is enabled to support design and execution of processes affecting PD objects.

Prerequisites

  • The Design Time Tool allows the process designer to specify the object type for the process.

  • The Design Time Tool allows the process designer to configure PD service for performing operations on multiple PD objects, Relationships, and PD infotypes.

Features

  • Operations based on InfoObjects

    The SAP_PD service is based on InfoObjects. The infotypes can be restricted by specifying a subtype. An InfoObject can be represented as follows: [infty, subty]. However, each InfoObject is tagged along with a 1000 Infotype OBJID Fieldname. As a result, an InfoObject can be called as a combination of OBJID_FIELDNAME, Infty, and Subty.

    Example Example

    The following table contains some examples of InfoObjects:

    InfoObject

    [1000, space]

    [1001, A003]

    [1002, 0001]

    [1007, space]

    [1008, space]
    End of the example.

    You can use InfoObjects to establish the relationship between form fields and infotype fields. Each InfoObject can be assigned an operation that is used on this InfoObject at the run time of the form scenario.

    The SAP_PD service supports the following operations:

    • Create

    • Change

    • Change without delimiting

    • Delete

    The effect of the operation depends on the time constraint of the InfoObject. The following three time constraints are used:

    • Time constraint 1: Exactly one data record exists at each time.

    • Time constraint 2: Exactly one or no data record exists at each time.

    • Time constraint 3: Any number of data records exists at each time.

    For example, the Create operation always creates a new data record for an InfoObject with time constraint 3, without modifying the existing records. However, an existing data record is first delimited for an InfoObject with time constraint 1 or 2. You can only ever enter one operation for an InfoObject. It is not possible to execute multiple operations on the same InfoObject (for example, create and delete).

  • Assigning form fields to InfoObjects, using P-Structures (PNNNN, PTNNNN)

    P-Structures enable access from form fields to the InfoObjects. At least one P-Structure exists for each infotype. Each P-Structure contains all infotype fields that are relevant for the user interface. These can be input fields or output fields (for example, for related texts or calculated fields).

    When assigning the form fields to InfoObjects, you have to choose one of the possible P-Structures of the infotype.

    There are no country-specific P-Structures in SAP_PD.

    As each InfoObject in a form scenario can be defined only once, you have to choose one P-Structure for each InfoObject. The input help displays the available P-Structures for you to select.

  • Using default values for form fields

    You can fill form fields with default values from the SAP_PD service.

    The following default value types are available:

    • Value for Effective Date

      Use this type if the form field is an input field and you want the value that “currently” exists on the database to be entered in the field as a default. The user can then retain the value or overwrite it. You have usually linked the form field to an InfoObject for which you have set the Change operation or Change Without Delimiting, and assume that data exists on the database that the user changes when editing the form. The mandatory field Effective Date (EFFECTIVE_DATA) determines the date on which the change in data becomes effective. The existing value for this date is determined as a default value. If there is no data record on the database for the effective date, no default value is determined for the form field.

    • Value for Day Before Effective Date

      Use this type if the form field is a display-only field that displays the previously existing value on the database. You will usually have defined another form field as an input field for users to enter the newly changed value. for example, in a process to change an organizational unit's name, there may be a display field that displays the old organization unit name and an additional input field for entering the new name. The change is to take place as of the effective date. In this case, you would choose the Value for Day Before Effective Date type for the display field. For the field in which the new position is input, you would choose the Value for Effective Date type. This means that the existing organizational unit's name as at the effective date is specified in the field as the default value for the new name. In the case of both types, if there is no data record on the database on the day previous to the effective date (=EFFECTIVE_DATE – 1), no default value is determined for the form field.

    • Default Value of Business Logic

      Use this type if the form field is assigned to an InfoObject for which you have set the Change operation. In this case, there is usually no data record on the database that could be used as a default value. If you use the Default Value of Business Logic type, the initial computation logic of the infotype is called and determines default values for the creation of a new data record. If the logic cannot determine a default value, no default value is entered in the form field.

  • Activating input help for form fields

    The SAP_PD service provides input help for certain form fields.

  • Mandatory form fields

    The SAP_PD service has a range of mandatory fields:

    Field Name

    Name

    Data Element

    LEAD_OBJECT_ID

    Lead Object ID

    ASR_FIELDNAME

    LEAD_OBJECT_TYPE

    Lead Object Type

    OTYPE

    EFFECTIVE_DATE

    Effective Date

    ASR_EFFECTIVE _DATE

    EFFECTIVE_BEGDA

    Effective Begda

    ASR_EFFECTIVE _DATE

    EFFECTIVE_ENDDA

    Effective Endda

    ASR_EFFECTIVE _DATE

    These fields must exist in each form scenario used by the SAP_PD service with the name exactly as specified and with the data elements exactly as specified.

    Note Note

    Do no delete these mandatory fields.

    End of the note.

Special Fields

The SAP_PD attaches special meaning to some form scenario fields. These fields are dealt with a specific logic inside the PD mapper.

  • Lead Object ID: The form scenario field LEAD_OBJECT_ID contains the Object ID of the Object that the process is based on. For processes with Start Object, the value of the LEAD_OBEJCT_ID is supplied by the Start Application. For processes without start object, this object ID is generated inside the PD mapper. This should not normally be empty; the only exception is when the operation on the LEAD_OBJECT_ID is 'CREATE'. In that case, the mapper's initialize method generates the object ID.

  • Lead Object Type: The form scenario field LEAD_OBJECT_TYPE contains the type of the 'Lead Object'. This information is always passed from the Start Application and must not be empty.

  • Effective Date: The form scenario field EFFECTIVE_DATE is treated as the effective date of the process. This field is never empty. The data element for this field is ASR_EFFECTIVE_DATE.

  • Effective Begin Date: The form scenario field EFFECTIVE_BEGDA is an optional field for SAP_PD service. When a value is provided to this field, it is used as the begin date for reading data or performing operations. This provides the flexibility for reading/updating data on a date range. The data element for this field is ASR_EFFECTIVE_DATE.

  • Effective End Date: The form scenario field EFFECTIVE_ENDDA is an optional field for SAP_PD service. When a value is provided to this field, it is used as the end date for reading data or performing operations. This provides the flexibility for reading/updating data on a date range. The data element for this field is ASR_EFFECTIVE_DATE.

As part of the enhancements to the Design Time Tool (DTT) to support SAP_PD back-end service, there are two tools available additional to the SAP_PA back-end service tools:

  • Objects Tool

    • This tool is part of the SAP_PD back-end service.

    • It deals with all aspects related to PD infotype 1000. It is used to capture the Object ID, Object Abbreviation (SHORT), Object Name (STEXT), the operation to be performed on the object.

    • The possible operations are derived through a search help: CREATE,READ, DELETE, UPDATE, MODIFY.

    • If the operation is empty or contains a value other than CREATE, it means the object and related fields are read.

    Behavior of the tool:

    • LEAD_OBJID is the OBJID field name of the Leading PD Object of any SAP_PD service.

    • Hence, the DTT by default, on inclusion of a SAP_PD back-end service into a form scenario, creates tools for that particular object.

    • Objects tool has a default entry in the table control for LEAD_OBJID. Also, the user can specify the OTYPE of the leading PD object and other related attributes.

    • For that LEAD_OBJID, there is a tool available to define any relationships that are created as part of the process, by also specifying RELATED_OBJID field name.

    • There is another tool to specify any other infotype's fields the form scenario deals with as related to LEAD_OBJID object of the form.

    • The tool can be used to specify all the PD Objects' field names on the form related to Infotype 1000 that are involved in the process.

    • As and when new entries are added into the tool, an event is raised to update the Object Browser Hierarchy dynamically to show tools to define Relationships, Fields, Infotypes, and Operations for the corresponding new PD Object with its OBJID_FLDNAME as the name.

  • Relationships Tool

    • This tool is part of the SAP_PD back-end service.

    • It deals with all aspects related to PD infotype 1001, which can be used to specify relationship fields on the form and define relationships across objects defined in the above Object tool.

  • Fields Tool

    This is an existing tool reused whose functions continue to be the same as in SAP_PA and SAP_PT. The user can use this tool to map fields from any PD infotype, even those from infotypes 1000 and 1001, which is not possible using the Objects and Relationships Tool.

  • Infotype and Operations Tool

    This is an existing tool reused whose functions continue to be the same as in SAP_PA and SAP_PT. The user can use this tool to specify explicitly the infotypes and operation whose fields he or she wants to map in the Fields tool.

    Additionally, the Process Start Configuration Main Tool is enhanced with a field to specify the object type of leading object ID. In the case of a process without a start object, specifying an object type the process deals with is mandatory.

Activities

Under Start of the navigation path Form Scenario Next navigation step Version Next navigation step Back-End Services End of the navigation path in the object hierarchy area of Design Time, make the following settings:

  • Definition of operations based on InfoObjects

    Specify the operations that you want to use and determine the sequence in which they are performed.

    If you only want to use an InfoObject to supply a form field with an input help or default value, do not enter an operation for the InfoObject. This is the case, for example, if you use the Objects infotype (1000) to output the object's name on the form. you always enter an operation if you want to modify the InfoObject on the database (as a rule).

  • Determining the time constraint of an infotype

    When defining the InfoObjects, always be aware of their time constraints as these affect the operations used. InfoObjects with time constraint 1 and 2 are usually no problem. However, there are restrictions for InfoObjects with time constraint 3.

    The time constraint of an infotype and subtype is also dependant on the object type.

    The time constraint is maintained in the maintenance view V_T777ZIT.

  • If you do not want the value of the form field to be included in the operation, set the Exclude from Operation indicator (OpAusschl).

    Note Note

    If you want an operation to be executed only in particular circumstances, you assign a rule to it. You must have previously defined the rule in the form scenario. you must have assigned all form fields that you use in the rule to the SAP_PD service. The assigned operation is executed only if the rule — based on the values of the from fields used — has the value “true”.

    End of the note.

  • You enter the record index. You usually enter the value 1. The following exceptions apply:

    • If you have set the Create operation for the InfoObject and the InfoObject has time constraint 3, it is possible to create more than one new data record.

      • If you only want to create one new data record, use the value 1.

      • If you want to create two data records, use the vale 1 for the fields to be included in the first data record, and 2 for the fields that are to be included in the second data record. You cannot start with the value 2 or higher.

      • If you want to create additional data records, raise the value of the data index by one for each new data record.

    • If you have set the Delete operation for the InfoObject and the InfoObject has time constraint 3, it is possible to delete more than one data record. Use the value 8 (asterisk) as the data index for this purpose. The asterisk means that all data records in the relevant time interval are deleted.