Details:
Action ID
This is a unique ID of the action that is passed into the ABAP user exits. When the status of the form changes, ABAP code can be used to interrogate the last performed action and perform the necessary operations.
Action Text
This is the text that appears on the button.
Icon
This is the SAP UI5 icon that is displayed on the button.
This is the styling that the button will use. You can see some examples of button types here.
Behaviour
This button opens up additional configuration options for the button.
| - Completes Task
When checked, performing this action will set the completion flag of the Task to true. The completion field is configured in the More section of the Task.
- Default Path
This indicates that this action will be performed if the Task requirements are not met and thus the Task will be skipped. This allows you to configure a chain of tasks that may be conditional. If a task is not executed due to requirements, the action with the Default Path option checked will be executed.
- Bypass Validations
This will ignore any validations on the form and is useful for actions such as Save as Draft.
- Go Back
When this option is checked, performing the action will take the user back to the Fiori Launch Pad, FAB Launch Pad or the My Forms app depending where they came from. Save as Draft is a good example where you do not want to take the user back and instead leave them on the form to continue working.
- Hidden Action
Checking this option will hide the button for the action on the Footer.
- One-List Action
This indicates that the action that can be performed by a user in the OneList application, where configured.
- Front-End Action Only
For front end only actions where no backend ABAP code is needed, the user can set this option that will prevent the form from doing any backend ABAP processing. Note: This will also mean that the data in your application will NOT be persisted to the backend.
- Validation Function
The Validation Function allows you to enter a JavaScript function name, which must exist in a Script element of the Form. This function is called when the Form is attempted to be submitted (if the ByPass Validations setting on the action is false). The function allows client-side validations to be performed before sending the data to the back-end. If the function returns false, the call to the back-end is aborted.
Generally, most validations are done on the back-end in SAP (via implementation class and method VALIDATIONS_ON_SAVE). This Validation function allows some checks to be made before sending the data to the back-end.
- Success Function
The Success Function is a JavaScript function which must exist in a Script element in the Form. The function is called after the call to the back-end is successful and allows a deviation from the default behavior (which is usually to exit the form) [if Go Back is true on the action].
Implement this function if you do not want to go back to the main menu when the action is successful, but rather go back to the previous Page and refresh the list on that Page. It can be useful where an app has two pages - the first one being a list, and the second the main detail page.
When a Success Function is configured, the application will not automatically Go Back. To go back to the Launch Pad after your function completes, you must call exitForm(evt) in your JavaScript function. - Prompt Function
The Prompt Function allows you to enter a JavaScript function name, which must exist in a Script element of the Form. This function is called before the action takes place. Implement this if you need to have a prompt asking for a user's input before the App can proceed with the action. The JavaScript function should call confirmAction(evt) if the action should execute.
|
Outcomes
This button opens an editor to configure the Outcomes when this action is performed. An Outcome is another task that can be in any level within the application. Each Outcome can also be configured with Requirements so that different outcomes can be configured depending on different requirements.
Standards / conventions / best practice guide
- Action ID's should be defined in UPPER CASE and contain no spaces by convention. If necessary, combine more than one word into an ID using an underscore. These are used in ABAP code, and as such should be similar to the Function Code values we define in a GUI Status.
- Action Text should be a verb or a (very short!) sentence fragment containing one or more verbs. This is the actual text that will appear on the button. For example:
- Please adhere to the Fiori guidelines for buttons where possible.
- Try to ensure that the 'main' button (used most often) is defined first, as the buttons will appear in the Process Flow toolbar (left to right) as they are defined in the designer (top to bottom).
