Saturday, April 5, 2014

MDS Seeded Customization Approach with Empty External Project

Great feature in ADF - MDS Seeded customisations support. This is particularly useful for independent software vendors, who are developing their own products on top of ADF framework. With MDS Seeded customisation, maintenance for multiple customers becomes easier. We could create customisation, instead of changing original source code - this makes it easier to maintain a product. I would like to share one important hint, related to technical architecture for MDS Seeded customisations - this will be related to the way how MDS Seeded customisations are organised and maintained. By default, you would create MDS Seeded customisation files in the original application, however this is not very clean approach. There is a way to create and keep all MDS Seeded customisation files in empty external application. I will describe in the post, how this can be achieved with a few easy steps.

If you are going to test sample application - MDSCustomizationsApp.zip, with integrated WLS instances in JDeveloper, make sure to read this post (it describes how to setup local MDS repository in file system) - How To Setup MDS Repository for Embedded WLS Instance.

Let's start - you can download initial version of sample ADF application from the blog post mention above. Employees form and empty Submit button:


I don't want to create any MDS Seeded customisation files inside, rather I would build and deploy ADF library out of main application:


Sample comes with special application - CustomizationApp (you can find it in the archive). This application was created to keep MDS Seeded customisation files, no other purpose. Initially, empty project was created - where ADF library was imported (the one we have just deployed):


Empty project is enabled with MDS Seeded customisation support:


Restart JDeveloper in customisation mode - so we could create some customisations for the content from imported ADF library:


If MDS Seeded customisation mode was successfully applied, you should see some special icon, next to the application name. Choose 'Show Libraries' to see a list of libraries - so, we could see contents from imported ADF library:


All attached libraries will be displayed, you should locate our ADF library. Expand it and you should see application packaging:


We could apply several customisations now. Let's open Employees VO and define View Criteria (filter employees by salary >= 1000). This customisation will be stored inside our empty project:


There will be a change in AM - View Criteria will be applied for VO instance:


We could go and review XML files for applied MDS Seeded customisations. There is one for VO and AM. XML for AM contains delta information about applied View Criteria for VO instance:


One more customisation on UI level now - drag and drop Commit operation for Submit button:


This change creates two additional XML files with MDS Seeded customisations - for JSF fragment and Page Definition:


You must define MDS Seeded customisations deployment profile (MAR) for application with empty project (containing XML's):


Development is completed, now will be a last bit - deployment. Make sure WLS is started (you should start it separately, if you want to test MAR profile deployment):


Go ahead and deploy main application first - you should get a list of MDS repositories (see a hint how to define local test repository in the blog post mentioned above):


Once main application was deployed, you can apply MDS Seeded customisations and export them through a MAR file from external application:


You should see main application name in the wizard, MDS Seeded customisations will be applied for this application:


All the changes applied through MDS Seeded customisations, will be visible in the log:


Good point - there is no need to restart main application, after MDS Seeded customisation changes were applied. Here you can see, original application with changes as per above:


If applied changes should be removed, this could be simply removed from MDS Seeded customisation XML file and re-applied. Main advantage of this approach - no need to store XML files with MDS Seeded customisations inside original project, we could keep them outside.

9 comments:

  1. Thanks Andrejus. As usual, great post

    ReplyDelete
  2. Thanks Andrejus.
    Although I had to restart from EM to apply the changes after deploy the .mar from EM.
    Do you know how I can undeploy the changes?

    ReplyDelete
  3. It depends what you customise, if you customize ADF BC - I think restart will be needed.

    Regards,
    Andrejus

    ReplyDelete
  4. Hi Abdrejus,
    It was a Seeded customization to set an attribute as isnotnull true, so that it's mandatory in the form.
    Do you know how I can undeploy the change? My workaround is to set the attribute to false (the inverse), but if you export the mds configuration you get a file setting the attribute to false.
    Would I have to use WLST Script for MDS Management as you explain in http://andrejusb.blogspot.com.es/2010/09/advanced-mds-management-for-oracle-adf.html or is there another alternative?

    ReplyDelete
  5. You could try to use MDS cleaner utility: http://andrejusb.blogspot.com/2012/04/red-samurai-mds-cleaner-v20.html

    ReplyDelete
  6. i get a "MDS-01800: Sandbox is not supported" error when I try to deploy the MAR, has anyone else run into this?

    ReplyDelete
  7. You can ignore this warning. MDS customisations will be applied successfully anyway.

    Andrejus

    ReplyDelete
  8. Hi Andrejus,
    I have a question, MDS doesnt persist bind variables with default values why is that? Do I need to set any property or it is default behavior?

    ReplyDelete