Technical Blog Post
Now you can see Registry Services by the DASHboard Light
There is beauty in visualization, there is paradise in beautiful integration, then there is a Meat Loaf-esque attempt at tying this entry’s title to the intro.
For the past two years we have been focusing on consolidating and correlating data from different data providers, and during that time we also put out a rather polished Registry Services Sample UI console that allowed people to browse data stored in Registry Services.
All the while we kept throwing a long look across the hallway - actually they sit on the floor above, their not so subtle way of looking down on us non-UI developers … assuming they ever find time to look at the floor, though I am almost certain some of them do, but I digress - towards all the cool visual integration possibilities available in DASH. The UI sample console remains a cutter knife next to the tool box offered by DASH, and what a tool box.
We started by modeling our OSLC Service Provider as a DASH data provider, then proceeded with modeling the OSLC Service Provider collection as a DASH data source, which quickly surfaced a number of possibilities that our standalone UI sample console realistically could never deliver with the same effort. We plan on expanding the support towards our other collections, but for now we have shipped a technology preview of two Service Provider datasets with the JazzSM 18.104.22.168 milestone 3 beta driver:
- A table of all OSLC Service Providers stored in Registry Services, containing the following fields
- Source URL
- URL in Registry Services
- Registration Records created by the Service Provider
- Resource Records associated with Registration Records created by the Service Provider
- Service Provider Record templates created by the Service Provider
- A tree-table of all OSLC Service Providers stored in Registry Services, containing the following fields
- URL in Registry Services
- Hierarchical relationships between Service Providers and OSLC Services
- Hierarchical relationships between OSLC Services and OSLC Creation Capabilities
- Hierarchical relationships between OSLC Services and OSLC Query Capabilities
How do I use it too?
As prerequisites, you will need DASH and a Registry Services database in place and already configured. The Registry Services dashboard data provider works directly against the data in a Registry Services database and does not require the Registry Services application.
During the installation of JazzSM, make sure you have the “Application –> Installation” and “Samples” features selected in the Registry Services installation package.
- If %FRS_DIR%\bin\setenv.bat (or setenv.sh if on a Unix platform) is not available, create one that is a copy from %FRS_DIR%\samples\sample_setenv.bat (or sample_setenv.sh, respectively).
Make sure the environment variables in the setenv file match the location of the middleware in your installation and include the following line, modifying the path to reflect the actual location of the WAS profile where DASH is installed:
set WAS_JAZZSM_PROFILE=C:\Program Files\IBM\JazzSMFP1\Profile
Note: I just realized today (11/4) that the servlet responsible for registering the Registry Services provider with DASH had a bug in its startup level, where in some cases it will not start by itself when DASH comes up, causing the datasources to not be visible in DASH. The workaround is to access this webpage to force it to load every time DASH is restarted: http://server:port/ibm/frs/oslc/Register
- Note that, although optional, if you have already configured the Registry Services database or application on the same WAS profile where DASH is installed, you don’t need to worry about this step.
If %FRS_DIR%\etc\CLI.properties is not available, copy it from %FRS_DIR%\etc\default\CLI.properties,
then review and modify it to match eventual differences in database hostname, port numbers, users, and passwords in your environment.
- Run %FRS_DIR%\bin\frs-curi.bat install -user <was_admin> -password <was_admin_password>
- Remembering that this feature works directly against the Registry Services database, and therefore does not require a running Registry Services application, you can optionally set a couple of configuration values to reflect the actual RESTful public URL of a running Registry Services application. This will be used in dataset columns representing the URL of records stored in Registry Services:
%FRS_DIR%\bin\frs config -set public.url=http://registry:port
%FRS_DIR%\bin\frs config -set public.url.context=oslc (this requirement will be removed in future sprints)
- Double-check the %FRS_DIR%\bin\setenv.bat (or setenv.sh if on a Unix platform) and %FRS_DIR%\etc\CLI.properties files in case you have modified your middleware locations, passwords or port numbers after installation, then run:
- %FRS_DIR%\bin\frs-curi uninstall -user <was_admin> -password <was_admin_password>
Updates after changes to the DB settings
If the database settings are modified, such as when a password expires or when you simply want to point at a different Registry Services database, you can also use the “update” parameter in the same CLI.
- Modify the database settings in the file %FRS_DIR%\etc\CLI.properties to match the new environment settings and run:
- %FRS_DIR%\bin\frs-curi update -user <was_admin> -password <was_admin_password>
More to come…
As we progress on the development of additional datasets, and there are some exciting possibilities in wiring widgets together to achieve cross-product data navigation beyond OSLC UI previews (which are already cool in their own right) , we look forward to your suggestions. You can leave a comment here or find out more about future stories under the Agile Epic on SMC.
I recorded a live demonstration of these two datasets working with the Registry Services data stored in the JazzSM hosted beta environment, which does not stop me from leaving behind a couple of teaser shots where they are paired with their obvious matches in the widget palette shipped with DASH.
Service Provider table
Service Provider tree table