Defining a New Request
To define a new request, first design and create a new Request business object then link that object to a new Request Type business object. The following sections highlight important details in setting up a new Request.
Request Display and Maintenance
The standard for new business objects is to use schema definition and UI hints to define user interface behavior. The business object lifecycle defines the actions to be taken. The alternative approach is to define explicit UI maps and handle any actions within the map. The base product business object F1-TodoSumEmailReq is an example of this method. The recommendation is to use the UI Hints approach.
Previewing a Request
- Request Preview Service Script. This script retrieves the information that is displayed when a user asks for a preview of a request.
- Request Preview Map. This map displays the preview of a request.
Note that the preview map is only necessary if the business object follows the explicit map approach, as per F1-TodoSumEmailReq. Business objects that use the schema and UI hints to define the user interface can utilize a map fragment to implement a preview action that invokes the preview script, using the script's schema to generate the preview map.
Performing Request Processing
The assumption is that an enter algorithm is responsible for request processing. It is common for requests to be processed in background rather than real-time. The standard technique is to use a deferred monitor to transition the request to the status that has the algorithm plugged in. The F1-TodoSumEmailReq lifecycle is an example.
Request Security
Some users may not be authorized to submit certain requests. When adding a new request, the list of available request types is restricted to types where the user has security access to the related request business object's application service. This may affect the choice of application service and the additional configuration required for a new request business object.