Slides 5-9) Lecturer
Give a recap of the general development procedure for creating a custom written Gateway service.
Slide 6)
It is helpful to point out that the Model and Data Provider classes are not required to have any programmatic relationship to each other.
For those people who are new to Gateway, this goes against their expectation because most programmers will assume that if the Data Provider class is going to supply information to the client, and that the Model Provider class defines the interface for that data, then it seems only natural that the Data Provider class would make direct reference to the Model Provider class in order to understand the shape of its own interface. This however, is not the case.
In spite of the fact that the Model and Data Provider classes are associated only by configuration, for convenience, it is useful to have the data types within the Model provider classes defined as public, so that the Data Provider class can reference them.
Typically however, the model provider will have public data types that can be referenced by the data provider class. This ensures that data structures and objects used by both classes are identical.
Slides 11-17)
Lecturer
These slides are self-explanatory in terms of the content, but the origin of the data model diagram requires some explanation. This diagram is created using the data modeller in Microsoft’s Visual Studio 10. This is a standard tool that comes with Visual Studio and will create an .edmx file. This file can then be imported into the Gateway system and used to generate a Model Provider class.
At the moment, this tool is not covered in detail in this training course because before people use a tool to generate coding, they should first be able to write the code manually.
A later version of GW100 will cover the model provider generator tool.
Slides 19-22) Lecturer
These slides are self-explanatory.
Slides 24-26) Lecturer
These slides are self-explanatory, but before diving into the coding, it would be a good idea to familiarise people with the interface of the model provider class. This interface is inherited from class /IWBEP/CL_MGW_ABS_MODEL.
Slide 28)
Lecturer
The next 4 slides are very important!
In chapter 1 section 3, we introduced the idea that OData properties could be mapped to standard Atom elements. These slides now explain how the coding for this functionality works.
For each Atom element that can be using as a mapping target, there is a method on the OData property object:
set_as_title() set_as_author() set_as_updated() set_as_published()
Calling any one of these methods will cause the value of associated OData property to be mapped to the Atom element named in the method name.
Slide 29)
Lecturer
Here’s the important part!
Calling this method does two things. The value of the Boolean parameter determines whether the OData property will appear in the <atom:content> element.
Excluding an OData property from the <atom:content> element could potentially cause problems during a CREATE or UPDATE operation because even if this value is supplied in the incoming XML, the fact that you have explicitly excluded this value means that the supplied property value will never be supplied to the data provider class, and your operation will always fail will a “Malformed URI syntax” error message.
Unfortunately, the SAP system provides is no further information about why the URI’s syntax is malformed… So this error may as well read “An error has occurred and I’m not going to tell you which one – good luck”.
Slides 33 & 31)
The slides show the difference in the resulting XML if the iv_keep_in_content parameter is set either to true or false.
Slide 33)
Lecturer
No matter how many times you warn the students, someone will always forget to update the class and structure reference string given in the bind_structure( ) method call.
Or they will complain that they have changed a data type in their model provider class but can’t see the change in the metadata. In this case, they have copied the sample solution and the class reference points not to their own model provider object, but the model provider object of the sample solution.
At design time, the character string passed to bind_structure( ) is just that – a character string. Its validity is not checked until runtime. This means that when you are writing the coding, you could enter any character string there you like (E.G. the recipe for chicken soup) and it would successfully
compile.
You will not discover whether the character string was valid until runtime. Therefore, tell the students to check the value carefully if they want to avoid runtime errors.
Slide 34) Lecturer
If there is an invalid class reference in the bind_structure() method call, then you will see an HTTP 500 error in the browser and a rather cryptic looking error in the error log.
Slides 35 & 37)
These slides are self-explanatory.
8. Chapter 4.3 – Developing a Model Provider
These slides are largely self-explanatory, but the following point should be emphasised:
• The Model and Data provider classes are independent ABAP classes that are not required to have any programmatic relationship with each other.
• In practice, it is helpful to create public types in the Model provider class and then use these as type definitions when declaring objects in the Data provider class. However, this is just for coding convenience, rather than a requirement.
• The name used for the “Technical Service Name” (also known as the “Internal Service Name”) will automatically become the External Service Name. Therefore, it is very important that the
Technical Service Name is chosen to be meaning to the end user – I.E. it does not start with Z and does not use some internal object name.
Slide 15) Lecturer
It is very important that the external name specified here is relevant and meaningful for the end user.
The only unusual thing about this configuration is that the name you enter for the Technical Service name (formerly known as the Internal Service name), is automatically copied to the External Service name and becomes the name seen in the URL – and therefore probably by the end user.
Slides 20-24) Lecturer
These slides are largely self-explanatory, but the following points should be emphasised.
Slide 20) Lecturer
Point out to the students that they will need to log on to the Gateway Hub server in order to perform this configuration. Within the context of the SAP training environment, the backend server on which they are performing their ABAP development, and the Gateway Hub are one and the same server (i.e., an all-in-one installation).
However, this deployment scenario for the Gateway add-ons is only to be used for training or intranet only service development.
In a “real life” scenario, the customer or partner should have a separate Gateway Hub server. When the students are back in their own development environments, it is the Gateway Hub server they should log on to in order to perform the following Service Catalogue configuration.
Slide 23) Lecturer
When adding a new service, two things are important:
1. For consistency and ease of transport management, the package name used for development of the Gateway Service in the backend system should also exist in the Gateway Hub server.
2. When you press the “Add Service” button, if you get the rather cryptic error message “Not all mandatory fields maintained”, then this is due not to any information missing from the visible