ADF Postback Payload Size Optimization. Recently I came across property called oracle.adf.view.rich.POSTBACK_PAYLOAD_TYPE. This property helps to optimize postback payload size. It is described in ADF Faces configuration section - A.2.3.16 Postback Payload Size Optimization. ADF partial request is executing HTTP post with values from all fields included. When postback property is set to dirty, it will include into HTTP post only changed values. As result - server will get only changed attributes, potentially this can reduce server time processing and make HTTP request size smaller. This especially can be important for large forms, with many fields.
Oracle ADF BC REST - Performance Review and Tuning.
I thought to check how well ADF BC REST scales and how fast it performs. For that reason, I implemented sample ADF BC REST application and executed JMeter stress load test against it. You can access source code for application and JMeter script on my GitHub repository. Application is called Blog Visitor Counter app for a reason - I'm using same app to count blog visitors. This means each time you are accessing blog page - ADF BC REST service is triggered in the background and it logs counter value with timestamp (no personal data).
ADF Performance Story - This Time Developer Was Wrong. ADF is fast. If ADF application is slow, most likely this is related to development mistakes. I would like to tell you one story, based on my ADF tuning experience. Problem description: ADF application runs fast in DEV, when DB size is small. Same application runs slow in TEST/PROD, when DB size is large. Question - what is slow. Answer - slow means forms are loading slow. Ok, lets go to the story.
ADF Client Side Validation with JavaScript. In my previous post I explained how to use JS client side formatter for ADF Faces input components - ADF Goes Client Side - UI Performance Boost with JavaScript. The same principle can be applied for client side validation. Most likely you are not going to implement complex validation rules on the client side, but for simple checks - it will be perfect. There will be no roundtrip to the server and this will allow to improve user experience.
ADF Goes Client Side - UI Performance Boost with JavaScript. If you would like to boost ADF UI performance, you should look into client side validation and formatting options possible to be done in ADF UI. Today I will describe how you can implement client side converter, to format number value on client side, without making request to the server. Same approach could be used to implement client side validators. You can raise error message and it will be assigned to UI field in the same way, just like any standard ADF error message. While this approach is documented long ago in Oracle ADF developer guide - How To Create Client Side Converter, it is not well known and not often used.
Skip LOV Validation for ADF BC Bulk Insert. This post is about ADF BC LOV. I will describe how you could optimize bulk insert of new rows into VO, when some of the attributes are assigned with LOVs. By default ADF would validate new row attribute value through LOV (LOV Validation and Programmatic Row Insert Performance) for each new row. This will lead to bad performance, especially if you insert a set of new rows programmatically - there will be multiple SQL queries executed to check if LOV attribute value exists.
ADF BC Range Paging and ADF UI Table Pagination Use Case. ADF UI table pagination and ADF BC range paging sounds like a perfect combination. But to make it work perfect, a bit of extra effort is required. In the case of search/edit implementation, it can't remember updated record when navigating back to search screen (VO runs with Range Paging and UI table is displayed with pagination). I will explain how to solve it and show how to keep UI table displaying current page and prevent jumping to the first page.
Monitoring ADF 12c Client Request Time with Click History. You must be excited to read this post, I will describe one very useful feature, available in ADF 12c. This feature - Click History. You can follow steps described by Duncan Mills, to enable and read click history data in server log. There is one more option available - we can read click history data from ADF request (captured by filter class) and log it in custom way (for later analysis). Click history gives such information as client request start/end time (you can calculate client request duration), component client ID, component type, action event type, etc. All this is useful to understand application performance perceived by the client.
Oracle JET and WebSocket Integration for Live Data. I was researching how to plugin WebSocket into JET. I would like to share my findings and explain how it works. It is amazing, how scalable and quick it is to send JSON message through WebSocket channel and render it in JET. Luckily WebSocket client is implemented in JavaScript, this integrates perfectly with Oracle JET (also based on JavaScript).
Database Change Notification Listener Implementation. Oracle DB could notify client, when table data changes. Data could be changed by third party process or by different client session. Notification implementation is important, when we want to inform client about changes in the data, without manual re-query. I had a post about ADS (Active Data Service), where notifications were received from DB through change notification listener - Practical Example for ADF Active Data Service. Now I would like to focus on change notification listener, because it can be used in ADF not only with ADS, but also with WebSockets. ADF BC is using change notification to reload VO, when configured for auto refresh - Auto Refresh for ADF BC Cached LOV.
Use Case of Auto Re-Execute Functionality in ADF BC. There are use cases, when data in DB is changed by background processes and we would like to display to the user latest data available. Very common implementation for this use case is to re-execute ADF iterator and VO each time when Task Flow or UI screen is accessed. Obviously this works, but performance would suffer - usually there is no need to re-fetch data each time, it must be re-fetched only when changes are detected in DB. ADF BC provides out of the box such functionality - it can detect changes in DB and re-execute VO through Database Change Notification. Make sure to grant CHANGE NOTIFICATION system privilege to the data source user.
Using Shared AM to Cache and Display Table Data. This post is based on Steve Muench sample Nr. 156. In my personal opinion, ADF samples implemented by Steve Muench still remain one of the best source of examples and solutions for various ADF use cases. Sample Nr. 156 describes how to use Shared AM to display cached data in UI table. Typically Shared AM's are used to implement cached LOV's (session or application scope). But it could go beyond LOV, based on the use case we could display cached data in the table or form. I have tested this approach with 12c and it works fine.
Auto Refresh for ADF BC Cached LOV. You can configure auto refresh for ADF BC cached LOV and this works out of the box, no special coding is needed. My previous post describes how ADF BC session cached LOV behaves - ADF BC Session Cached LOV - Understanding Expire Time. Auto refresh can be configured for both application and session caching. One important thing - auto refresh doesn't work when ADF BC is configured with disconnected mode (ADF BC Tuning with Do Connection Pooling and TXN Disconnect Level). I would guess this is related to DB notification listener, it can't notify about DB changes, when DB connection is being taken from AM.
ADF BC Session Cached LOV - Understanding Expire Time. ADF BC offers LOV caching feature. There are two caching levels - application and session. With application level enabled, it makes LOV rows available for all users. On contrary for session level LOVs, data is cached for single session only. In this post I will focus on session level LOV's and I'm going to explain when cached data expires and is re-fetched.
How To Record ADF Client Side Request Performance Time. I had a blog post, where I have described how to monitor client side request performance time with Ajax tag (works in ADF 12c) - Monitoring PPR Request Time on ADF UI Client Side. There is effective way to propagate recorded statistics back to the server for history logging using WebSockets - WebSocket Integration with ADF for PPR Request Monitoring. This requires WebSockets integration into project, if project doesn't allow this - there is another way. We could leverage Ajax call to the Java servlet and pass logged statistics data through parameter. I will describe how this can be achieved.
ADF and Two-Way WebSocket Communication Architecture. This post is based on WebSockets and ADF, topic described in the previous post - WebSocket Integration with ADF for PPR Request Monitoring. I would like to look into it from technical architecture perspective and split WebSockets server logic into separate application deployed on WebLogic. WebSocket is two-way (bidirectional) communication channel, this allows to send and received data at the same time. I'm going to demonstrate how it works with my sample application.
WebSocket Accelerated Live Data Synchronization for MAF. New generation Mobile and Web applications are going to use WebSockets. This is one of the fastest and convenient ways to transfer JSON formatted data from the server to the client and back. Huge advantage - server could initiate data synchronisation request and deliver JSON messages directly to the client. You should read my previous post about detail information how to configure MAF with WebSocket - Oracle MAF and WebSockets Integration - Live Twitter Stream.
Oracle MAF and WebSockets Integration - Live Twitter Stream. Oracle MAF and WebSockets - I will describe how it works together. WebSockets is a protocol providing full-duplex communication channel over a TCP connection. This channel is interactive (communication is both ways) and we can send messages from the server to the client (MAF application running on the device). There is no need to use push notifications, WebSockets provide JSON support and allow to send complex payload data. In a way it competes with REST, however REST is different with request is being initiated by the client. WebSockets data is received automatically - there is no need to trigger any event by the client.
WebSocket Integration with ADF for PPR Request Monitoring. WebSocket is a protocol enabling communication over TCP connection. Communication is interactive, meaning data can be sent both ways - from the server to the Web client and back. Data is sent through WebSocket channel, without using using regular HTTP. This means we can enable communication between server and Web client without consuming bandwidth from HTTP. WebLogic 12c is shipped with required libraries for WebSocket support, we can use this protocol straight away in ADF 12c. WebSocket supports JSON format, this allows to send and receive JSON formatted data, just the same as REST. In this post I'm going to describe how WebSocket could be used, to report PPR request time measured on the Web client (Monitoring PPR Request Time on ADF UI Client Side), back to the server.
