The following user-exits are available to enhance Transport Expresso for specific requirements of the end client:
| User Exit | Description |
| Validation during saving of a Transport Form (Exit Identifier 0010) | When a transport form is being saved by the user, this user-exit enables one to do whatever is necessary (for example validation of the input data). |
| Get extended task list items (Exit Identifier 0020) | When searching for a Task in the “Task Search” dialog, it is possible to retrieve other tasks from, for example, external systems in this user-exit. |
| Action Confirmation (Exit Identifier 0030) | Implement this exit to override whether a particular action within Transport Expresso requires confirmation, as well as the behaviour of the confirmation dialog. Possible actions are:
A = Approve a task (or set of tasks)
I = Import a transport request (or set of transport requests)
T = Save test results and finish testing Errors can be issued by setting the return structure Y_RETURN by calling function module /BTI/TE_RETURN_GET, passing in the message details: message type, message ID, message number and variables. Set parameter XY_CONFIRMATION_REQUIRED=X to force Transport Expresso to ask the user to confirm their actions. |
| Validation during saving of a Task (Create or Change) (Exit Identifier 0040) | This user-exit is called during the creation or changing of a Task (after the save button is selected). Refer to User Exit 0620 for a user-exit prior to display of the Task. The mode is passed through (Create or Change) as well as the values that have been entered. Based upon this, the user-exit can issue a message to the user to prevent the creation/change of the Task or add additional data behind the scenes. |
| Check for duplicate task reference during saving of a Task (Create or Change) (Exit Identifier 0045) | This user-exit is called during the creation or changing of a Task (after the save button is selected). A flag can be set to indicate whether the task reference field can accept duplicates values or whether it must be unique. |
| Dependency Check (Exit Identifier 0050) | This user exit is called during dependency checking. |
| Transport import (Exit Identifier 0060) | This user-exit is called during the transport import process. It allows specific actions to be carried out during the import process. |
| Change clients during import process (Exit Identifier 0065) | This user exit is called during the import process to override the clients used for client dependent imports. By default TE will import into all configured clients for the relevant target but this user exit allows the list to be adjusted if there are any special rules. E.g. only import transports originating in client 200 into client 210 and ignore clients 100 and 110 |
| Merge request creation in participating systems (Exit Identifier 0070) | This user exit is called at the point where either a merge request or a backup request is to be created in a participating system. It is possible to override the standard functionality for creating these requests within this user exit. |
| Merge request processing (Exit Identifier 0071) | This user-exit is called during the processing of merge transports. This can be used to influence how the merge requests are created. For example, the standard implementation can be used to create a new merge transport for every source transport being merged. |
| Load User List (Exit Identifier 0100) | Implement this exit to override the list of users that will appear in Transport Expresso when choosing administrators, approvers and managing the list of users whose transports are being displayed. The main user details like user ID, first / last name, email address, etc. can be returned. |
| Load Test User List (Exit Identifier 0110) | Implement this exit to override the list of users that will appear in Transport Expresso when choosing test users within tasks. The main user details like user ID, first / last name, email address, etc. can be returned. |
| Integration: Mapping before sending (Exit Identifier 0200) | This exit is called during the integration process to allow data to be mapped according to specific rules before it is sent to the receiving system. |
| RFC destinations (Exit Identifier 0310) | This exit can be used to manipulate the name of the RFC destination that is used when connecting to remote systems. For example, it can be used to override the default destination based on the system ID to point to an alternative system. |
| Pre-population of emails during notification (Exit Identifier 0510) | This exit is called during the notification engine just prior to any emails being sent. This means that all email details that have been derived, the subject, message body and recipients are provided to the user-exit for alteration if desired. |
| Post-population of emails during notification (Exit Identifier 0520) | This exit is called during the notification engine but after each email has been sent. During this exit you can send further emails if desired. |
| Pre-population of a Transport Form (Exit Identifier 0610) | When a Transport Form is initially created, this exit is called prior to the Transport Form appearing. This enables the default values of the Transport Form to be pre-populated. It also enables attachments to be automatically added as well as dependencies to other transport requests. |
| Pre-population of a Task (Exit Identifier 0620) | When a Task is either initially created or changed, this exit is called prior to the Task form appearing. All fields of the Task can be defaulted or changed prior to display of the form. More importantly, both the default set of Testers and the default set of attachments can be pre-populated. |
| Pre-population of a Test Result (Exit Identifier 0630) | When a Test Result (via a Task and a Test Queue) is initially created, this exit is called prior to the Test Result appearing. The Test result has only 2 fields that can be pre-populated (Test Result and Test Description). More importantly, however, you are also able to attach file templates within this exit. Hence, attachments such as Test Documentation can be added to the Test Result automatically upon entry of the Test Result. The user then has the option to either populate the template or to remove it (if required). Please note that the context of the Test Result (i.e. the Test Queue control point) is also passed to this user-exit along with the Task details so that the behaviour can be altered dependent upon this context (e.g. one template for Integration Testing and another for User Acceptance Testing). Task Search Results Filtering (Exit Identifier 0640) This user exit is processed during the task search process. It can be used to further filter the list of tasks returned by the search to build in any customer specific checks. For example, it could be used to additionally search for the entered text within custom fields. |
| Transport Request Travel (Exit Identifier 0710) | When a transport request moves from one location (e.g. Inbox) to another location (e.g. Import Queue) it is possible to manipulate the movement of the transport request within this user-exit. In particular, one is able to “skip” control points and even entire systems if desired (e.g. if the transport request is of a particular type). It is also possible to release the transport request automatically after movement into a particular control point (e.g. after approval is given and the transport request moves into an import queue of a given system then perform the auto-release). |
| End of Transport Request Travel (Exit Identifier 0720) | This user exit is called at the end of the transport path travel function module. By this stage the location of the transport form will have been updated and this can be used, for example, to trigger the creation / sending of TE notifications. |
| SAP Transport Request Creation (Exit Identifier 0730) | This user exit is called during SAP transport request creation. It can be used to set defaults for the transport request details like description, owner, target and project. |
| After Merge Request Creation (Exit Identifier 0810) | This user exit is called after the creation of merge request. It can be used to automatically create a transport form for the new merge transport. |
| Merge CTS+ Processing (Exit Identifier 0820) | This user exit is called during the processing of CTS+ transports. It can be used obtain the timestamp for the CTS+ transport objects for use in overtake and conflict checks. |
| Post Import Processing (Exit Identifier 0850) | This user exit is called after transport import is complete. It can be used to carry out any required post processing activities on the imported transports or the created merge requests. For example, it could be used to perform the BW renaming on created BW merge requests. |
| User Exit for global check in General Analysis (Exit Identifier 0900) | Used to set the global check flag during the general analysis. Setting the global check flag will mean that the general analysis will look at all transports in the path whether created locally or imported from other systems. |
| RFC client destination for conflict analysis (Exit Identifier 0910) | This user exit is called during the conflict analysis process to override the RFC destination and therefore the client used. By default the client in the merge target will be used for the conflict analysis but it can be overridden to check a different client if required but using a different RFC destination. E.g. check client 100 for conflicts with transports originating from this client but check client 200 if the transport originates from there |
| Web UI News feed filtering *(Exit Identifier 0920) * | This user exit can be used to restrict and filter the news and recent events items returned for the logged in user so they don’t see news relating to all users. |
Post your comment on this topic.