Showing posts with the label ADF BC REST

ADF BC REST service - Batch Processing

Source: GitHub

ADF BC REST services provide us with an interesting tool for bulk data processing - the batch process. The following article demonstrates how this feature can be quite helpful in reducing the volume of our code, and making our DML operations smooth.

As the name suggests, batch processing allows you to perform multiple DML operations in a single web service call.

A batch process is sent as a POST request, but there are 3 important ways a batch process differs from a standard POST request:

1) The base URL only goes till the rest URL pattern or the REST version.
2) The content-type header is "application/".
3) Each DML operation in the batch is identified by a unique ID and an operation name ("create", "update" and "delete"). It is this ID which is referred to by the framework while reporting an error.

The body of the POST operation consists of an array of objects of the following structure:

ADF BC REST service - Type Mapping

This article talks about a powerful, yet under-utilized, feature of ADF BC - the data type mapping. Oracle ADF provides this feature to generate a runtime mapping between a View Object's String attribute and a Web Service's (both SOAP and REST) Boolean attribute.
The most popular use-case for this feature is to map a Boolean Active/Inactive flag from the service to a Yes/No value on the View Object. By default, ADF provides 3 mappings, which cover the following scenarios:
1. oracle.jbo.valuemaps.BooleanYNPropertySet - maps Y/N to true/false. 2. oracle.jbo.valuemaps.BooleanTFPropertySet - maps T/F to true/false. 3. oracle.jbo.valuemaps.Boolean10PropertySet - maps 1/0 to true/false.
These property sets are in adfm.jar, which is part of the ADF Model Runtime library.
The advantage of using a type mapping is a two-way binding - you may pass the String as well as the Boolean value in the payload, and the type mapper automatically translates to the required value t…

ADF BC REST service - Attachments

Source: 1) ADF BC REST, 2) Oracle JET application

Continuting on the previous discussion on ADF BC REST - Type Mapping - the framework can be stretched further to work with uploading files and images. Working with attachments is an important aspect in any commercial application; and ADF BC REST service provides us with a robust mechanism to store and display files and images through BLOB columns.

The following article discusses both about developing the REST service for storing documents in an Oracle database, as well as configuring an Oracle JET application which uploads and displays an image on the GUI.

The REST API I have added a PROFILE_IMAGE column of BLOB type to the employees table in the HR schema, and I will use this column for storing my attachments. BLOB columns are handled in a slightly different way by the REST API. The BLOB column is not included in the actual payload, but it comes as part of the links section, as an enclosure attribute.

The href value c…

ADF BC REST service - defaulting with CREATE method


This is more like an update on my previous article - ADF BC REST - NULL and DEFAULT, where I spoke about the various ways null data can be defaulted via a REST API. However, there was one use case which I had missed - the CREATE method of EntityImpl.

There is an interesting behaviour which may be observed when, instead of  setting a default value declaratively on the entity attribute, we override the CREATE method of the EntityImpl subclass.

When a value is set in the create method, this value takes precedence, irrespective of whether we pass null, some value or don't pass the attribute in the payload at all.

To demonstrate this, I will set a value of 25000 for Salary attribute in the create method.

And I will pass the below payloads:

For all the three payloads, the data gets saved with salary 25000, the value with which it was initialized in the create method, irrespective of the fact that I also have a declarative default value for the Salary entity attribute.


JDev: Source: GitHub
This article talks about an interesting difference between passing null and no value for a column in the payload of an ADF BC REST end-point. Now this might seem a bit obvious in the end, but nonetheless, it can be confusing at times.
To demonstrate this problem, I have the following use-case: Set a default value for employee "Salary" during insert or update!
Now your GUI might have some required validation set on this field, and it does not allow the end-user to save the form without a non-zero salary. That is all good. But your QA might have an automation running to check the REST APIs with their own payload. And this is something which needs to be in sync with the UI logic.
To get started, I have my Employee entity object with a default value of 5500 for Salary field.

Case # 1: Payload does not contain Salary attribute

When I submit this payload, I get back an Employee object with the default Salary of 5500, as declaratively set up on the e…

Querying ADF BC REST service - RowFinders and REST Shape

JDev: Source: GitHub
This article talks about querying ADF BC REST services using a RowFinder, and displaying different data sets based on our needs, using REST Shaping.
REST Shaping This is a powerful tool provided by ADF BC to determine the kind of data you can expose to the end user.
Imagine this use-case where we need to display certain attributes of an employee on the front-end application depending on whether we have an anonymous or an authenticated user, while we retain all the features of the view object (View criteria, custom SQL etc). Creating multiple copies of the same VO is certainly not an option.
REST shaping allows you to create metadata on the view object, identified by a unique name, where you can specify which columns may displayed and which all may be hidden.
See examples below, which show two shapes created - AuthView and NoAuthView, each showing different data sets.

Important Note: Each REST instance supports a single REST shape. I did not find any way …