ABAP_to_the_Future

13
SAPUI5
Understanding the Structure of an SAP Gateway Service Implementation
To get an idea of what an SAP Gateway service implementation looks like, go back
to your SEGW transaction, select your Z_MONSTER service, and expand the Service
Implementation and Monster Set nodes. You’ll see the CRUD operations (Figure
13.20): Each one is represented by a generated ABAP method, into which you
have to put some code.
Figure 13.20 CRUD Classes that Need Some Code
In fact, there are four classes that have been generated by the system for each
project. The first two are an abstract class called (in this case) ZCL_Z_MONSTER_DPC
(where DPC stands for “data provider cl ass”) and a class that inherits from this
called ZCL_Z_MONSTER_DPC_EXT, which you can and will change. In the abstract
class, there are methods for create, read, and so on, but all they do is raise an
exception, so you need to redefine them all. The second two classes have almost
the same names as the first two, exce pt they have MPC instead of DPC (MPC
stands for “model provider class”); take a look in the code for ZCL_ZMONSTER_MPC,
and you will see generated code that sets up the data model based upon the configuration
settings you’ve made.
To reiterate, the data provider class stores transactional methods, which you need
to redefine, and the model provider class stores the data model, which you do not
need to change, because it was created based on the settings you made setting up
the data model.
Note that there are two types of entity (monster and monster item), but both entities
live in the same project and are thus manipulated by the same service. Thus,
the CRUD methods for each type of entity are all in the same DPC class.
Coding the CRUD methods is not actually going to be a major problem, because
you already have the monster model class, which does all of these operations. The
582