Numerous user exits points are available to enhance ActiveControl for specific customer requirements.
|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).|
|Validation of a locked/unlocked Transport Form (Exit Identifier 0011)||When a Transport Form is locked or unlocked by the user, this user-exit enables one to perform any required function.|
|Transport Form creation (Map User) (Exit Identifier 0012)||Can be used to map users during Transport Form creation process (incase the userid is different in Development and Domain Controller)|
|Get extended task list item (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 ActiveControl 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 ActiveControl 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. It should be noted that this user exit cannot be used to update custom fields.|
|Validate transport creation from task (Exit Identifier 0041)||This user exit can be used to validate the populated Transport Form from Business Task information.|
|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 ActiveControl 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
|Non SAP Change Import (Exit Identifier 0068)||Can be used to deploy non-SAP changes from within ActiveControl|
|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.|
|Set form fields for merge (Exit Identifier 0072)||This user-exit can be used to set fields for auto merge form creation. It has been largely replaced by configuration options within the Windows GUI in later versions of ActiveControl|
|Task creation webservice preprocess (Exit Identifier 0080)||This user-exit can be used to perform webservice pre-processing during Business Task Creation. This needs to be activated to enable custom fields (e.g. CF_500) to be saved in the in the header structure for task creation|
|Task read webservice postprocess (Exit Identifier 0081)||This user-exit can be used to perform webservice post-processing during Business Task read|
|Task change webservice preprocess (Exit Identifier 0082)||This user-exit can be used to perform webservice post-processing during Business Task change. This needs to be activated to enable custom fields (e.g. CF_500) to be saved in the in the header structure for task change|
|Task test results webservice preprocess (Exit Identifier 0083)||This user-exit can be used to perform webservice pre-processing during Test Results entry|
|Task approval webservice preprocess (Exit Identifier 0084)||This user-exit can be used to perform webservice pre-processing during Business Task approval|
|Task get transports WS postprocess (Exit Identifier 0085)||This user-exit can be used to perform webservice pre-processing to get Transport list from Business Task|
|Integration conversions (Exit Identifier 0090)||This user-exit can be used to perform conversions as part of Integration|
|Integration notifications (Exit Identifier 0091)||This user-exit can be used to perform alternative notifications as part of Integration|
|Load User List (Exit Identifier 0100)||Implement this exit to override the list of users that will appear in ActiveControl 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 ActiveControl when choosing test users within tasks. The main user details like user ID, first / last name, email address, etc. can be returned.|
|Before Transport Release: Runs in target (Exit Identifier 0120)||This exit can be used to perform target activity prior to transport release.|
|Extra validation in Inline Risk Analysis (Exit Identifier 0130)||This exit can be used to perform additional validation during the conflict analysis process.|
|Integration exit: Mapping before sending message (Exit Identifier 0200)||This exit can be used to perform mapping activity prior to sending Integration message.|
|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.|
|Modify list of approvers (Exit Identifier 0500)||This exit can be used to modify list of approvers for web gui and notification engine, prior to Delegation.|
|Filter transports for approval (Exit Identifier 0505)||This exit can be used to filter list of transports awaiting approval.|
|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).
|Test Result validation when saving (Exit Identifier 0635)||This user exit can be used to validate the entered Test Results during save process.|
|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 ActiveControl 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.|
|SAP Transport Request Approval, before Travel (Exit Identifier 0740)||This user exit is called during approval, before the actual travel takes place.|
|Merge Request Creation (Exit Identifier 0800)||This user exit is called during the creation of merge request. Note that this user exit is deprecated in more recent versions of ActiveControl.|
|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 to 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.|
|Post Import Processing (single tp/client) (Exit Identifier 0851)||This user exit can be used for post processing activities on the imported transports, per single transport/client deployment.|
|Post Import Processing (unconditional) (Exit Identifier 0852)||This user exit can be used for post processing activities on the imported transports.|
|TOC Creation (Exit Identifier 0855)||This user exit can be used to create Transport Form for Transport of Copies.|
|Add to Import Queue (Validation) (Exit Identifier 0860)||This user exit can be used to validate the allowed Import Queue locations whilst trying to perform an Add to Import Queue action in the Windows GUI or Web UI.|
|Add to Control Point (Validation) (Exit Identifier 0861)||This user exit can be used to validate the allowed Add to Control Point locations whilst trying to perform an Add to Control Point action in the Windows GUI or Web UI.|
|Add to Import Queue (Change Locations) (Exit Identifier 0862)||This user exit can be used to alter the list of locations you can choose whilst trying to perform an Add to Import Queue in the Windows GUI or Web UI.|
|Add to Control Point (Change Locations) (Exit Identifier 0863)||This user exit can be used to alter the list of locations you can choose whilst trying to perform an Add to Control Point Queue in the Windows GUI or Web UI.|
|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.|
|Link creation validation (Exit Identifier 0930)||This user exit can be used to validate link creation.|
|Priority Schedule Filter (Exit Identifier 0940)||This user exit can be used to perform a filter on Priority Schedule.|
|Overtake Analysis Filter (Exit Identifier 0950)||This user exit can be used to perform a filter during Overtake analysis process.|
|Custom Field updates on Transport Form save (Exit Identifier 0960)||This user exit can be used to update custom fields on Transport Form when saving the Transport Form.|
|Custom Field updates on Transport Form save (Exit Identifier 0961)||This user exit can be used to set custom fields to read/write based on any conditions.|
|Custom Field updates on Transport release (Exit Identifier 0970)||This user exit can be used to update custom field on transport release (if Transport Form already exists). This is called after is called after transport release (class /BTI/CL_IM_TE_BADI_TR_REL).|
|Exclude objects from analysis (Exit Identifier 0980)||This user exit can be used to exclude unnecessary objects from an analysis|
User Exit Implementation
If a user exit is to be implemented, simply copy the sample function module which has a naming standard of /BTI/TE_EXIT_SAMPLE_XXXX (where XXXX = 4 digit user exit number) into the customer name space. This copies across the signature of the function module (Importing, Exporting, Changing, Tables and Exception parameters). The copied function module should then be amended to the client’s specific requirement.
Once implemented, an entry must be added to table /BTI/TE_EXITC in the ActiveControl Domain Controller. A corresponding entry may also need to be added to /BTI/TE_EXIT if it does not already exist and has been shipped.
The entry in /BTI/TE_EXITC requires:
|EXITID||This is the User Exit identifier such as 0010, 0020, etc.|
|COUNTER||This is just the sequence number, starting from 01. However, if the user-exit allows multiple exits to be defined, then this can be incremented for each implemented user-exit (i.e. 01, 02, 03, etc).|
|EXITFUNC||The function module name defined in the customer namespace (e.g. ZABC_TE_EXIT_0010).|