All standard tasks have to implement the interface /PCH/IF_BPF_TASK_TYPE. For separation of concerns, a separate meta data class with the suffix _DEF is recommended.

Method	Description

Method	Description
GET_META	Definition of several control flags: EV_IS_EXECUTABLE - If true, the standard task can be executed (providing the action execute and a corresponding implementation). Any new Task should be executable and provide an corresponding implementation. EV_IS_REJECT_EXECUTABLE- If true, the standard task can be executed if the user performs a rejection. EV_STATUS_MODE - Defines the status mode of the standard task. Currently only manual and automatic status mode is available. If in manual mode, the status of the task is set by the user, if in automatic mode by the standard task and cannot be set by the user. EV_IS_REPEATABLE - If the standard task is executable, this setting controls if the execution can be performed only once or multiple times. EV_IS_AUTOMATIC - If true, the standard task is executed automatically without any user interaction. Currently not supported. EV_WF_TASK - If the standard task requires a special SAP workflow standard task, it can be defined here. Currently not supported.
GET_CUST_EXTENSION_DEF	Is optionally used to provide a list of Designer UI Extension definition instances.
GET_RT_EXTENSION_DEF	Is optionally used to provide a list of Designer UI Extension instances.
GET_HANDLER_SAPGUI	Optionally provide the name of the class, which handles the action in SAP Gui (see SAP Gui Handler ).
GET_HANDLER_SAPUI5	Optionally provide the necessary information about a handler in the SAP Fiori My Inbox app .
CHANGE_ACTIONS	Based on the task business object instance, the task container and customizing data, the actions (icon and text) in the task list of the user can be overridden by the standard task.

More detailed information is available on the corresponding Data elements of the Meta data control flags.

A task type with reject executable must be of status mode automatic as reject executable is currently not supported with manual status mode.

Basic connection between executable, reject executable, repeatable and status mode

A task type which is not executable never has an action execute (respective a corresponding handler) and therefore the options all other options are ignored and implicitly treated as: not reject executable, repeatable, status mode manual.
A task type with status mode automatic must set the task status in the executer according to the function the user executed as the user is not able to change the status himself.
A task type of status mode manual (not reject executable), can be rejected and reset as long as the task has never been executed. Afterwards the user is only available to switch between Completed and Started.
A task type of status mode manual must be executed at least once by the user in order to complete the task. Afterwards the user can either set the task to Completed (if not done by the task implementation) or can repeat the execution if the task is repeatable.
A task type of status mode manual can be "reset" (set to status Started again) by the user it it is repeatable from Completed or Rejected.
A task type which is not repeatable cannot be reset or executed again after the first action (execute, reject, set to Completed or set to Rejected). This applies to both manual and automatic status mode.

Using other interfaces, the meta data class can be enriched by more meta data as described below:

Please note, that in the basic meta data interface more than one instance of definition classes can be retrieved for the extension of the runtime user interface and for the extension of the designer user interface (see methods GET_CUST/RT_EXTENSION_DEF). If more than one definition instance is required, obviously multiple, separate classes are needed. If just one implementation is required it is recommended to implement these interfaces in the same class as the basic meta data interface.

The other interfaces (enhancement of customizing task and container system) must be implemented in the same class as the basis meta data interface.

Examples of Meta data settings and their effects

Task Setting “Repeatable” includes EV_IS_REPEATABLE of the task meta data and the definition in the Designer.

Task settings	Effect	Example

Task settings	Effect	Example
Meta Data EV_IS_EXECUTABLE : False EV_IS_REJECT_EXECUTABLE: n/a EV_STATUS_MODE: n/a Settings Repeatable: n/a Rejectable: n/a	User can mark the task as Completed and revert the Completed status No task related action is executed when user marks the task as Completed if the task is defined as mandatory, the user has to mark the Task as Completed in order to proceed.	Text task
Meta Data EV_IS_EXECUTABLE : True EV_IS_REJECT_EXECUTABLE: False EV_STATUS_MODE: Manual Settings Repeatable: False Rejectable: See description	The user has to Execute the Task, in order to be able to mark the Task as Completed. Depending on the task implementation, the Completed status can be set automatically. If the status is set automatically, the user cannot revert from Completed. If the user has to mark the task as Completed the task manually, the user cannot revert after marking the Task as Completed. The user cannot Execute the task again, as per definition of the task. If the task is defined as mandatory, the user has to mark the task as Completed in order to proceed. If the task is defined as rejectable: The user can Reject before executing the task once. After executing the task once, the user cannot Reject the task. If the task is mandatory, the user can also mark the task as Rejected in order to proceed.	Create Object
Meta Data EV_IS_EXECUTABLE : True EV_IS_REJECT_EXECUTABLE: False EV_STATUS_MODE: Manual Settings Repeatable: True Rejectable: See description	The user has to Execute the Task, in order to be able to mark the Task as Completed. Depending on the task implementation, the Completed status can be set automatically. The user can revert from Completed. The user can mark the Task as Completed after the task has been executed at least once. The user can execute the task again. If the task is defined as mandatory, the user has to mark the task as Completed in order to proceed. If the task is defined as rejectable: The user can mark the task as Rejected without executing the task even once. The user can mark the task as Rejected while it is not Completed but cannot while the task is Completed. The user has to revert from Completed before. If the task is mandatory, the user can also mark the task as Rejected in order to proceed.	Change Object
Meta Data EV_IS_EXECUTABLE : True EV_IS_REJECT_EXECUTABLE: False EV_STATUS_MODE: Automatic Settings Repeatable: See description Rejectable: See description	The user can Execute the Task. The status Completed has to be set automatically by the task implementation. The user cannot set the status Completed manually. The user cannot revert from Completed. If the task is repeatable: The user can Execute the task again. If the task is repeatable and rejectable: The task can be marked as Rejected if the task has not been executed, but cannot be Rejected after it has been executed at least once. The user can Execute the task, even if the task has been Rejected before which must Complete the task via the task implementation. If the task is rejectable but not repeatable: The user cannot Execute the task after the task has been marked as Rejected.	Create ECM
Meta Data EV_IS_EXECUTABLE : True EV_IS_REJECT_EXECUTABLE: True EV_STATUS_MODE: Automatic (must) Settings Repeatable: See description Rejectable: see description	The user can Execute the task or Reject the task. If the task disables the Reject Action, the action is not available and cannot be executed. If the task is repeatable: The user can execute the available actions again. This means the user can Execute the Complete or Reject action again (e.g. to change the selected statement), or Execute the other action. If the task is not repeatable: The user can Execute only one of the actions available. A switch (Completed to Rejected or vice versa) is not possible. The user cannot Execute the selected action (Execute/Reject) again. The implementation for Complete and Reject must be provided by the task itself. The task implementation is responsible for correct status and data handling if the user switches between Completed and Rejected. If the task is rejectable is determined by the task implementation during runtime. The task can disable the Reject action if appropriate.	Statement

Runtime UI Extension

Using a Runtime UI Extension a standard task can override the default status (e.g. completed or rejected) in the UI. This might be useful to show some information created within the standard task instead of the standard text and icon. For a Runtime UI Extension the interface /PCH/IF_BPF_RT_EXTENSION_DEF has to be implemented.

Method	Description

Method	Description
GET_RT_EXTENSION_CLASS	Provide the name of the class, which handles the runtime extension.

Customizing Task Extension

The interface /PCH/IF_BPF_CUST_TASK_EXT can be used for overriding some options of the task. As soon as an option is overridden it cannot be change by the user any more and is therefore greyed out.

Please note, that this overriding mechanism is very static. Options cannot be changed based on other task options or standard task customizing data.

Method	Description

Method	Description
OVERRIDE_PROTOCOL_MODE	Override the protocol mode. Even though any mode can be set, it is recommended to use this method only to force a protocol to be mandatory.
OVERRIDE_REJECTABLE	Override if a task is rejectable. If the standard task is not rejectable at all, this will be recognized automatically and the option will not be available to the user. Therefore, it is not necessary to override the option with the value false, if rejection is not supported, but can be used to force rejection to be available.
OVERRIDE_EXEC_BY_RESPONSIBLE	Override if a responsible is allowed to execute the task.

Designer UI Extension

Using a Designer UI Extension, a standard task can extend the process designer by additional, standard task specific data and UIs on different levels of the process hierarchy. For a Designer UI Extension the interface /PCH/IF_BPF_CUST_EXTENSION_DEF has to be implemented.

Method	Description

Method

Description

GET_CUST_EXTENSION_CLASS

Provide the name of the class, which handles the customizing extension.

GET_TYPES

The ProProcess types on which the customizing extension should apply. Because of the hierarchy possible values are:

Task
- Activity
  - Part process
    - Process

The possibility of extending not only on a task but also on higher levels (e.g. process) makes it possible to reduce maintenance redundancies, because it might make sense to set up standard task specific information on a top level and inherit them automatically to all standard tasks of the same kind.

Container Extension

Standard tasks can handle and store their data completely on their own. If they do so, they are not accessible by other objects of the process. ProProcess therefore uses the concept of containers, which can be used to exchange data in a generic way. By implementing the interface /PCH/IF_BPF_CONTAINER_ITEM_DEF container item definitions can be provided. Of course, the data must be set by the standard task at runtime.

Method	Description

Method

Description

GET_ITEMS

Provides a list of container items. The importing container id can be ignored, because the container is handled by ProProcess. Container Items consist of the following attributes:

ITEM_ID - A unique alphanumeric item id.
ITEM_TYPE - The type of the item (see /PCH/CL_BPF_SRV_CCONTAINER=>C_ITEM_TYPE). Please note that classes are not allowed since they cannot be persistent.
ITEM_DATATYPE - The SAP data type of the item.
IMPORT - If true, the value can be set from outside. Will be automatically set to true, because otherwise the task could not write the container data.
EXPORT - If true, the value can be accessed from other objects.
MANDATORY - Mandatory items need a value at design time. For standard tasks, it should always be set to false.
PERSISTENT - If true, the data of the item is stored within the container system. Non-persistent items are currently not supported.
VALUES - Provide values at design time. For standard tasks, this information must not be provided.
ID_FIELDS - Used for translating values containing temporary ids at design time. For standard tasks, this information must not be provided.

GET_ITEM_DESC

Retrieve the description of an item in the current language (sy-langu).

GET_MAPPING_PROPOSAL

Currently not supported.