How does DCN work?

[hofmann]

Data Change Notification (DCN) sound impressive and when taking a closer look at the description, it looks like it is the best of both worlds:

• Up to date data in the CDB
• Minimum impact on the backend

Create MBO

First step is to create a MBO that is assigned to a cache group that uses DCN. Pick a service you want and create a MBO from it. I’m using my user web service published on Geronimo.

The MBO is assigned to a cache group that uses DCN.

From the MBO perspective, that’s all. The MBO is created with attributes and operations and assigned to a DCN policy. The MBO can be deployed on SUP.

Data Change Notification

Data Change Notification means that you have to take care for filling the cache database (CDB). While with the other policies SUP takes care of making sure that the data in the CDB is loaded from the backend, with DCN this is your task. When your application logic demands that data entered into the backend needs to be made available to the MBO, you have to write an application that does exactly that.

For sending data updates from the backend to SUP and the CDB you’ll need custom code. The data change notification is send to a servlet. This servlet runs on the SUP server and waits for connections under the location /dcn/DCNServlet (for basic authentication): http://server:8000/dcn/DCNServlet

As outlined in the SUP documentation, a DCN request has to follow a very strict and specific layout.

http://server:8000/dcn/DCNServlet?cmd=dcn&username=user&password=password&package=ProjectName:Versio...{"pkg":"dummy","messages":[{"id":"1","mbo":"MBOName","op":":upsert","cols":{values}}]}

Security

To be able to send data to the DCN servlet you need to be authenticated. When you now expect some fancy SSO or token stuff: nothing of that. Its plain simple HTTP authentication:

• username and password or
• base64

The actual data change send from the server to DCN servlet can be either with or without payload (once the data is send as a parameter added to the URL (GET) or as data in the request (POST)). SUP makes it simple to send the data: no REST, just a plain GET or POST. The communication is only between your backend and SUP. Depending on your infrastructure it depends if you should or have to use SSL for DCN communication.

You can access the DCN servlet using your browser to see if the servlet is running:

In case you were wondering what kind of application server SUP is running on: it’s Jetty. Maybe sometimes SUP will run on Tomcat (or TomEE) or even NetWeaver AS Java.

DCNServlet requires a valid user. Make sure that the user you are passing in the argument list exists in the domain and security configuration and has the needed role. If not, you get this error message:

Note that the MBO is deployed in a security domain called Android, the default supAdmin does not exist in this security configuration.

Loading data

Full request:

http://sup:8000/dcn/DCNServlet?cmd=dcn&username=android22&password=password&package=TestDCN:1.0&doma...{"pkg":"dummy","messages":[{"id":"1","mbo":"TobiasMBO","op":":upsert","cols":{"id":"10","city":"Brasilia","userName":"testDCNUser"}}]}

When the use passed is valid, you get:

Verify CDB

The response message states “success”. But how to know that it worked? Is the MBO updated? As it’s not always useful to create a mobile application just to know what the MBO returns, you can also analyze the content of the Cache DB. See the How-To document posted on SCN to see how to do so.

Executing the query:

Result:

That is exactly what was send to SUP. DCN is working!

While DCN is a great way to keep the CDB synced and minimizing the impact on the backend, it’s comes with some serious amount of work. Not only will you have to implement DCN for each MBO and trigger the data refresh. Each time you change the structure of the MBO you’ll have to adjust your custom code too. When you use one SUP server for DEV and QA, you really have to ensure that the DEV DCN code is not pushing data to the QA MBO. With good governance DCN gives you the most flexibility.