Skip to Content
The CAF & BO concepts nicely hides away the ‘dirty work’ of implementing relational tables & writing boiler-plate codes for mundane (but need to have) data operations for Create, Retrieve, Update & Delete (CRUD) of those tables.

However, this layer of abstraction comes with a price tag:
These out-of-box operations of the BO lacks certain functionalities we desire, e.g. perform aggregration type of queries (e.g. GROUP BY, HAVING).

The following demonstrates how a customized operation can be implemented at the BO level, through providing a GROUP BY functionality to the BO.
It uses the JPA framework as the underlying mechanism to achieve this customized functionality.
The same principle applies to developing any other types of operation at the BO level.

We assumed the readers are familiar with the SAP CE tools for creating & testing a CAF application with BO (i.e. NWDS, Service Browser)
Some basic knowledge of how JPA works is also assumed.

1. Create your BO object as usual; below is an example.

2. Populate your table using your BO in Service Browser.
In this example, the columns are populated with values to demonstrate the GROUP BY example.

3. Now for the interesting part: Create a new BO operation using the standard wizard.
You should see something similar to screen capture below.
The default method type is FINDBY and return type is always tied to the class of this BO.

The CAF framework auto generates the method implementations for this new operation inside the BO Bean class.
We will leave them alone.

Looking inside the BO Bean class, the auto generated method implementation is as follows.
Leave the code alone but take note of the method signature.

4. To use JPA directly, we need to find out the auto-generated entity class that is tied to the underlying table.
Find the class using the Project Explorer view; it is typically named: [Your BO name]

The actual entity name is indicated here. This also the name we will use as part of our JPQL coding.

5. It’s time to implement the customized logic.
a. Open the provided [Your BO name] & overwrite the same method contained in parent BO bean class by using the signature we obtained in step 4 above.
It is important to maintain the return List type in generic format to ‘by-pass’ the compiler complaints.

b. Implement your logic, using the _entityManager attribute & JPQL coding.
The _entityManager attribute is injected in our parent BO Bean class which we inherited; so we utilize it for our purpose.


6. Deploy the application. But using the Service Browser to test the custom BO operation directly will result in an error.
This is because the Service Browser Web Dynpro application expects the returned List to only contain our BO class type but in our case it contains a list of Object[ ].

7. Instead, we will test this new operation instead via our application service implementation.
a. Create a custom complex type reusable for returning aggregated query results.

b. Create a new application service operation.
Our service operation takes in an input parameter to make the logic extensible to group by other types.

c. Define return type accordingly (in this case a list of AggregateModel types).

d. Code the logic to invoke the BO custom operation.

8. Finally, test the application service operation in Service Browser.

This above technique probably deviates from the true spirit of having the BO shielding you from the underlying JPA entity & its mechanisms.
But sometimes, you just need that ability to intimately interact with your data source.

We hoped this shows how the standard BO framework can co-exist in harmony with customized usage of the JPA framework.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply