This is the forth step of the series. You’ll find an overview in the document Introduction.
In this step we will create the third entity set, the business partner one. Just creating another one is not very interessting but with this example we will see how to use BOPF associations to implement associations in the GW project. This feature will be used to implement the detail page of the service. So let’s start.
Using associations in BOPF is a comfortable mean to navigate through the space of business objects without having to know how exactly the data relates – for it is implemented once in the association. The same advantage applies for associations in an OData service: The UI developer does not have to know about the relational constraints between the data but can just use an association.
To begin with the business partner entity set will be mapped to the business object /BOBF/EPM_BUSINESS_PARTNER. This BO has an foreign key association to the main address. The business partner entity type will be enriched by attributes of the main address – just like the product name in the step before.
The new feature introduced here is the definition of associations and the implementation via an association mapping with SADL. On the detail page of the product we want to display further informations about the supplier, hence the business partner. This means that we have to navigate using the foreign key relationship from the product to the supplier.
This video illustrates the step.
Modifying the Gateway Service
We will again modify the service as in the previous step Implicit Viewbuilding with the Gateway Service Builder (transaction SEGW). We go roughly through the data model definition and implementation before focusing on Associations. Last but not least we test the navigation in the Gateway test client.
Definition and Implementation of the Business Partner Entity Set
As already described in the previous step, we need an entity type and an entity set.
The entity type for the business partner consists of some properties which can be provided by the root node of the business partner BO – like business partner ID, company name and legal form. Then we need some properties which will be populated by the address node following the ToMainAddress association.
So select the Create button in the right mouse menu of the Data Model folder and define the properties. The Business Partner ID is the key – as human readable and unique identifier.
The wizard creates already the related entity set.
Set the flags accordingly.
Now again we will use the implementation wizard ‘Map to Data Source’ and select BOPF als source type and /BOBF/EPM_BUSINESS_PARTNER~ROOT as source entity. This opens the mapping editor and we define the mapping using drag and drop.
So far nothing new compared to the previous step.
Creating and Implementing an Association
I already mentioned that we want to follow a foreign key relationship from the product to the supplier. Hence we are going to define an association from the product to the supplier.
First we have to enhance the data model of the service and second to implement the association. So open the right mouse menu in the Data Model folder and select the create function.
This starts a wizard where you can enter the association name and its attributes.
The Principal Entity is the source of the association – the ProductHeader. The Dependent Entity is the target of the association, hence the BusinessPartner. Define the cardinality and mark Create related Navigation Property for your convenience.
Normally you define the referential constraints in the next step. As we want to map the association to a BOPF one, we must not define them redundantly. So delete the proposal.
You can just finish the wizard.
The wizard has created the related Association Set and a Navigation Property for the ProductHeader entity type. That’s it for the definition. It follows the mapping.
Associations are attributes of the source entity. So we open now the mapping editor for the ProductHeaderSet.
On the left hand side of the editor, the associations are displayed. Just drag and drop the BOPF association to map it. That’s it. Save and activate the service and go for testing.
Testing the Service
Back to the Gateway client you can test the new entity set just like in the step before. And now you can follow the association from a product to its supplier. Select a product. Memorize the supplier id to verify the result of the next step. Then add the navigation property name (BusinessPartner in the example) to the URI for the product.
Execute the GET method and you will navigate to the supplier.
The metadata section contains information about the navigation and a direct link to the target of the association. This will be needed in the step about the Creates and Updates.
To learn more about SAP NetWeaver Gateway go here.
Creating the SAPUI5 page
Let’s go ahead with using these new capabilities of the OData service in our UI and create the product detail page.
The video illustrates this step.
First we have to create a new view for the product details – just like in the previous step. But this time it is a detail page and we add it as such to our splitter application in the index.html file.
The index.html file
The view creation wizard provided already the detail view and controller files, so we can first focus on the navigation to the page. The navigation starts with the selection of a product on the product master page – hence in the listItemTriggered callback function of the product controller.
The Product Controller
We are using the same binding context for the details view. The path is referenced in the binding context. We have to set it now. As it changes with every selection we first destroy the old one. We have to configure the http request so that it expands the data selection via the navigation property BusinessPartner. Hence we set the expand parameter accordingly.
So the details view is now bound to the selected product and the related business partner information.
The Details View
In the view itself we have to define a form for the product and business partner details.
We are using a grid with two columns, one showing product details, the other one showing business partner details. The interesting thing is the data binding. In the product controller we’ve already set the path to the selected product and expanded the data retrieval to the business partner. We now have to use it on this page. The properties of the product can be referenced by its name, even if they originate from a joined BOPF node. The properties of the business partner are referenced using the navigation property: <navigation property>/<property name of the navigation target entity set> – hence BusinessPartner/CompanyName for example.
The Details Controller
Just a quick view on the details controller file: it binds the data model with the view.
After having saved and submitted the files, we are ready for tests.
You can see the two columns and the detail data which is displayed after having selected a product.
The application is not very nice. The detail form is displayed independently if a product is selected or not – just without any data displayed if nothing has been selected. We will not continue on improving this, as it is not important in the context of the backend connection. It’s pure work on the UI part. See some ideas of improving the UI in step 6.
For the navigation from the categories to the products, we used the search function of the OData service in setting a filter. For the navigation from the product list to the product details we used a navigation property of the OData service. Which one is the appropriate mean depends on your backend. Any way you can combine the methods and choose always the best suited.
Now we want to enable editing the product and business partner details. There are some specials to be considered and this is the topic of the next blog: Modifying Associated Data.