Provisioning an Oracle Fusion Middleware domain is made easy with Rubicon Red MyST Studio, but with so many parameters for customization in your Platform Blueprint or Platform Model things can get a little complicated.
There are, however, a few little tricks to make your life better, among which the ability to make a field mandatory in MyST Studio.
This post is part of a Series in which Robert Jan de Groot and I explore the inner and hidden parts of Rubicon Red MyST Studio which might come in handy at times.
Let’s say you have an OFMW domain whirring away somewhere, and you need to add a new JDBC Data Source to it. Here’s how to make that happen for all environments like the one we discuss here.
MyST has a nice system of hierarchy going on: Platform Models inherit a lot of their configuration from Platform Blueprints. This means that you often only have to configure it once in your Blueprint to be able to use it many times in your Models.
We’ll discuss this method in more detail below.
First off, we’ll create the JDBC Data Source in our Platform Blueprint, after this we supply the correct information for our environment in the Platform Model.
We’ll show a way to make a field mandatory by utilizing a little trick up MySTs sleeve.
Defining your Data Source in Platform Blueprint
Navigate to your Platform Blueprint, and in there go to ‘WebLogic Domain Configuration‘ -> ‘ JDBC Data Sources‘. Click on the plus-sign to add a new JDBC Data Source.
Here, type in the name of your Data Source. We opted for ‘DocumentDataSource‘.
Add the required information to this Data Source:
Name: DocumentDataSource
Targets: soa_cluster
User Name: DOCUMENTUSER
JNDI Name: jdbc/Document
URL: ?
Password: ?
Question marks?
Yes, question marks.
This is the trick to make MyST know a field is mandatory, even when it technically is not.
We choose to make both ‘URL‘ and ‘Password‘ mandatory, as they differ over the environments (OTAP) we have, and we have to ensure these fields are set (correctly!) for all environments.
This way, we avoid the situation where someone punches in the connection information for the PRODUCTION environment in the Platform Blueprint, and someone else carelessly forgets to alter it in their Platform Model for a new environment.
In this situation, your brand new testing environment would talk to PRODUCTION (or at least tries to when everything is firewalled) and that is never a preferred situation.
By setting the value to ‘?‘ we make sure MyST requires you to give a meaningful value in your Platform Model.
If you don’t do this, you’ll be greeted with an exception stating that your Platform Model is not valid, and that you should modify it by setting a value to the fields which contain a question mark. Just what we need!
What would happen?
When you’d just run an update on MyST, you’ll see the log like below:
Agent invocation log MYST_HOME=/opt/myst-studio MYST_WORKSPACE=/u01/app/stage/mystWorkspace/ba79cac9-9ad3-4f5e-8009-1ddeb06e9842 ------------------------------------------------------------------------ R U B I C O N >< R E D MyST vRC (207) ...delivery...deMySTified.............................................. (c) 2011-2016 Rubicon Red Software Pty Ltd. All rights reserved ------------------------------------------------------------------------ Registered to : EMAILADDRESS=maarten.tijhof@rubix.nl, CN=RubiX, L=Den Bosch, ST=Brabant, C=The Netherlands Expires : Tue Nov 13 07:20:13 CEST 2021 Session ID : 11-06-18-08-25-47-20451 ------------------------------------------------------------------------ Analysing request... There are references to properties which do not exist: core.domain.jdbc-data-source[rxr.wls.JdbcDataSource-7].jdbc-driver-params.url references to property: ------------------------------------------------------------------------ Unable to resolve all properties. Execution has been halted after 2 Seconds For debugging information please check logs/myst-diagnostic.log
MyST is somewhat cryptically complaining about references which do not exist, and points to a JdbcDataSource-7 that does not seem to have a url set. And that is correct!
We set it to a question mark, and MyST just ignores that.
To ‘fix’ this, we just have to start editing our Platform Model and fill in the required fields.
Fixing the issue
To get MyST to play nice again, we just have to override the fields containing a question mark.
Navigate in your Platform Model to ‘WebLogic Domain Configuration‘ -> ‘ JDBC Data Sources‘ and click on the Data Source ‘DocumentDataSource‘. Start editing your Model, and fill in the required fields with the proper values.
Now Save & Commit your Platform Model, and all is ready!
MyST will not complain about these fields anymore when you provision or update an environment, as they contain real values now and your MyST Action will not fail because of this.
Recommendations
There are numerous fields where you would want to require the user to fill in a specific value in the Platform Model, as a default value could be potentially dangerous or risky.
Apart from the example we discussed here (JDBC Data Sources) making a field mandatory in a Platform Model could be valuable for the following list of items:
- Database URLs
- JMS SAF endpoints
- Passwords for users on foreign databases
When you think of other possible uses for making fields mandatory, please let us know by either reaching out via twitter @maartentijhof or by leaving a comment below.
