ADF 12c provides out of the box support for ADF BC REST API. It is straightforward to create ADF BC REST service and run it. But what if you would like to expose ADF BC REST for existing ADF application with ADF Faces UI. This could be useful if there is a requirement to handle ADF Bindings access to ADF BC along with light ADF BC REST service API implementation for Oracle JET or other JavaScript clients. The same ADF application could handle two types of client access - ADF Faces and REST.
When you create ADF BC REST application, JDeveloper creates REST Model and WebService projects. Technically speaking, if you have existing ADF application with Model and ViewController, you could add third project for REST Web Service by yourself. Two configuration files are required - web.xml and weblogic.xml (if ADF Security is enabled):
ADF BC REST is exposed to the client through ADF servlet. It doesnt work to enable ADF BC REST servlet in ADF Faces project web.xml. This requires to have separate WAR deployment for ADF BC REST and different context root.
ADF Faces and ADF BC REST are sharing the same ADF Security context and this means we are using the same set of Application Roles for both.
In my example, ADF Bindings are mapped with Employees VO instance - this brings data to be displayed in ADF Faces:
The same VO instance is exposed through ADF BC REST:
ADF BC REST servlet is defined in REST project web.xml. It doesnt work to define it in the same web.xml where ADF Faces are configured - context conflict error comes on runtime. Thats the reason why I have separate WAR for ADF BC REST:
There is one WAR for ADF Faces app and one for ADF BC REST. Both WARs are packaged into single EAR. This means there is one deployment, but two context roots, one for each WAR:
If you download my sample app and want to run it, make sure to build REST project first:
Then click Run for ADF Faces app - ADF BC REST WAR will be packaged automatically (if you deploy it on standalone, simply build EAR - it will include both WARs):
We can see it in the deployment log - both WARs are packaged into single EAR:
This is the result - ADF Faces UI is accessed through adfapp context root:
ADF BC REST from the same application is accessed through restapp context root, authenticated with the same ADF Security context as ADF Faces app:
When you create ADF BC REST application, JDeveloper creates REST Model and WebService projects. Technically speaking, if you have existing ADF application with Model and ViewController, you could add third project for REST Web Service by yourself. Two configuration files are required - web.xml and weblogic.xml (if ADF Security is enabled):
ADF BC REST is exposed to the client through ADF servlet. It doesnt work to enable ADF BC REST servlet in ADF Faces project web.xml. This requires to have separate WAR deployment for ADF BC REST and different context root.
ADF Faces and ADF BC REST are sharing the same ADF Security context and this means we are using the same set of Application Roles for both.
In my example, ADF Bindings are mapped with Employees VO instance - this brings data to be displayed in ADF Faces:
The same VO instance is exposed through ADF BC REST:
ADF BC REST servlet is defined in REST project web.xml. It doesnt work to define it in the same web.xml where ADF Faces are configured - context conflict error comes on runtime. Thats the reason why I have separate WAR for ADF BC REST:
There is one WAR for ADF Faces app and one for ADF BC REST. Both WARs are packaged into single EAR. This means there is one deployment, but two context roots, one for each WAR:
If you download my sample app and want to run it, make sure to build REST project first:
Then click Run for ADF Faces app - ADF BC REST WAR will be packaged automatically (if you deploy it on standalone, simply build EAR - it will include both WARs):
We can see it in the deployment log - both WARs are packaged into single EAR:
This is the result - ADF Faces UI is accessed through adfapp context root:
ADF BC REST from the same application is accessed through restapp context root, authenticated with the same ADF Security context as ADF Faces app:
Download sample application - ADFFacesRESTApp.zip.
No comments:
Post a Comment