II. ANÁLISIS DE LAS VARIABLES CLÍNICAS Y
10. Conclusiones
Lecturer
When going through these slides, it is a good idea also to follow the instructions they give in the ABAP editor. These slides act very much like a how-to guide; however, you should always be a practical demonstration rather than simply conducting another session of “death by PowerPoint”.
Slides 5, 6, 8)
These slides are self-explanatory.
Slide 10)
Lecturer
Before diving into the details of how the generator tool works, you should explain the fundamental principle that each of the CRUD operations exposed by a Gateway service needs to be implemented by mapping it to existing functionality within the SAP system.
By “existing functionality”, we mean a BAPI or a custom written remote-callable ABAP function module, or a simple Dynpro screen.
In the screen shot, point out the fact that each of the operations, QUERY, READ, UPDATE and CREATE is mapped to a specific BAPI.
Slide 12)
Lecturer
Emphasise the fact that the “OData Channel” check should not be switched off for several reasons:
• The Generic Channel object model is being deprecated
• The structure of ABAP objects generated by the OData Channel object model is much simpler than that generated by the Generic Channel
• You cannot use the new debugging facilities with the Generic Channel object model (i.e. the sap-‐ds-‐debug=true query string parameter)
Slide 13)
Lecturer
What might be a little unusual here is the fact that we select “Remote Function Call” yet on the next few slides, we will be using BAPIs. This is not wrong, because all BAPIs are simply RFC modules that have been written to implement the method of a business object.
All BAPIs are RFC modules, but not all RFC modules are BAPIs.
The only implication of this design decision is that if you call a BAPI as if it were a normal RFC module, then the Gateway Framework quite reasonably assumes that the RFC module will take care of its own database COMMITs. All BAPIs however rely on the fact that in the same ABAP session that they have executed, a subsequent call to BAPI_TRANSACTION_COMMIT will be made. If you call a BAPI as if it were an RFC module, then there will be no subsequent call to BAPI_TRANSACTION_COMMIT and any updates made by the BAPI will be rolled back when the invocation finishes.
To avoid this problem, apply SAP note 1688265.
The training system has had this note applied.
Slide 15) Lecturer
Screen shot is not shown here due to overlapping animation events.
This slide simply shows how to use the search tool to locate the required function modules.
Slide 16)
This slide is self-explanatory.
Slide 18)
Lecturer
The important point here is that BAPI_BANK_GETLIST has a mandatory input field – BANK_CTRY.
MAX_ROWS is also flagged as mandatory, but the coding in the BAPI accepts an initial value in this field.
If we left the field mapping in the state shown in this screen shot, we would create a situation in which the QUERY operation could never run successfully. This is because a mandatory field has not been mapped to the OData interface, neither has it been assigned a constant value; therefore, no matter what parameter values you try to specify in the client, the function module will always issue the error message that “Bank Country has not been specified”.
Remember that the first time we attempt to run this service, we will have deliberately left out the BANK_CTRY field from the OData. This is to illustrate what goes wrong if mandatory input fields are forgotten.
Slide 19)
Lecturer
Describe how to add the mandatory input field to the OData interface (that is, the column on the right labelled “Mapping Route”). This column name is not really that helpful. It should really say something like “Field in OData interface”.
⍟ The BANK_CTRY field needs to have its mapping route changed, so select the filed by right-clicking on it and press “Change Mapping Route”
⍟ A pop-up will be displayed in which you can select the field in the OData interface to which the selected field should be mapped.
⍟ Once the mapping selection is complete, the name of the field to which the BAPI field is mapped is shown in the Mapping Route column.
Slide 20)
Lecturer
Alternatively, you might have a situation in which the mandatory input field does not need to be available in OData interface, because it will only ever have a fixed value.
In this case it is acceptable to omit the field from the OData interface because you have defined a constant value for the field.
IMPORTANT
Even though the constant value is defined within the ABAP system, you must still follow the OData syntax rule that all non-numeric parameter values must be specified in single quotes.
⍟ Select BANK_CTRY and press Set Constant Value
⍟ In the popup window, enter the required static value – do not forget to enclose it in single quotes!
⍟ Press enter and the value is now assigned.
Its important to understand here that the value BANK_CTRY will still not appear in the OData
interface. So no matter how hard you try, you will never be able to override the static value by passing in a value in the URL.
Slide 21)
Lecturer
This slide does not show a configuration step. Instead it highlights the fact that the person generating this Gateway service needs to understand not only how to call each BAPI, but how the data coming out of one BAPI should be used to supply input values to the next BAPI in the sequence of business process steps.
The typical sequence of operations is QUERY, then READ, then UPDATE. Therefore, when creating a Gateway service, you need to determine which fields on the output side of the QUERY operation will be needed to supply information to the input side of the READ operation. Similarly, the data coming out of the READ operation must be mapped to the input values belonging to the UPDATE operation.
Slide 22)
Lecturer
By preparing the students with the comments of the previous slide, you have now laid the foundation of why it is necessary for a Gateway service to have at least one key field.
Once one or more key fields have been defined, they become the fields in which data can be transported out of one operation and into another.
Slide 23)
Lecturer
In the ABAP system, show how the data coming out of the QUERY operation is placed into the key fields, which are then used as input to the READ operation.
Slide 25)
Lecturer
Although the SAP system does not enforce this, a valid OData service should always implement at least the QUERY and READ operations.
Slide 26, 27)
These slide are self-explanatory.
Slide 28)
Lecturer
All the fields that appear in a data structure on the output side of a BAPI or RFC interface will need be flattened. What this means is that the fields have their mapping route changed so that they belong to the root node rather than (in this case) BANK_ADDRESS.
The reason for this is that currently, a generated OData Service cannot supply fields in a data structure without you needing to issue a second HTTP request from the client. By flattening the data structure, all the data is presented to the client in a single HTTP request.
Also, the data coming out of a READ request must typically be supplied into a subsequent UPDATE request. This cannot be done by a generated Gateway service if the fields are part of a data structure.
Slides 29, 30, 32, 34-37) These slide are self-explanatory.
Slide 39)
Lecturer
The procedure shown here assumes that the Gateway Service has been built in the same system as the Gateway Hub. This will always be true for generated services, but for custom developed OData Channel services, this assumption will not necessarily be true.
If a customer developed OData Channel service is to be exposed, then you will need to click on the
“Add Service” button, then specify the system alias of the system in which you developed the service.
Only then can the service name be chosen from the list shown in the screen shot.
Slide 40)
Lecturer
As mentioned previously, the service will only appear immediately in this list if it was created in the Gateway Hub – all generated services will therefore appear here immediately.
The easiest way to locate a service is to sort the list by external name.
Slides 41, 42, 44-47)
These slides are self-explanatory.
Slide 48)
Lecturer
Hopefully, you will not have forgotten to leave out the BANK_CTRY field from the OData interface – otherwise, you will not be able to demonstrate this error.
Slide 49)
The BANK_CTRY field that was omitted from the interface is now added and the service is regenerated and rerun.
Slide 50) Lecturer
Screen shot is not shown here due to overlapping animation events.
The important point to emphasise here is that the value of the $filter query string parameter, is itself, a selection clause with it own internal syntax.
There must be a space, or a URL encoded space (%20) on either of the logical operator.
All non-numeric values must be enclosed in single quotes.
Field names are case-sensitive!
Slide 51)
Lecturer
Now that the $filter parameter has been used to define a value for the bank_ctry field, the Gateway service works correctly.
Slide 52)
Lecturer
Refer back to the chapter in which we introduced OData.
Within each <atom:entry> element in a collection, there is an <atom:id> element that contains the full URL for accessing that particular collection entry.
Notice the syntax used to access a specific element uses a key predicate, not a $filter command.
This is how we can change a QUERY request (that returns a potentially large number or entries) in to READ request that returns at most, a single entry.
Slide 53)
This slide is self-explanatory.