Community
Participate
Working Groups
Data managers have values that need to be configured at deployment time. These values include: - display name - description - MDR ID (for CMDBf MDRs) These values can be put in a configuration file, and provide a web service operation in the data manager web service to retrive the values. The MDR ID is of particular interest, which is used in CMDBf queries and registration for identifying an MDR. We should revisit the problem of uniquely identifying data managers with this enhancement. Currently, data managers are identified by the axis2 service group name and the hostname. The axis2 service group name is garenteed to be unique per axis2 container. Together with the hostname, the two values form a unique key. (One assumption here is that we don't have two servers on the same host.) If we have a common strategy for specifying MDR ID, we can generalize that as a way to specify unique identifiers for all data managers. Some config values can be locale specific. Need to decide whether these values are cached at the broker. The data manager toolkit can provide ways to help set up the config file.
Two deployment instances of the same MDR need to have different MDR IDs. This is to support having multiple instances of the same MDR. It's a use case CA brought forward.
*** Bug 232165 has been marked as a duplicate of this bug. ***
Is this still being considered for i12? If so, it needs to be mapped to a use case and there will need to be a design, in order for it to be approved. I am asking since this ER will impact other defects that might need to be scheduled for i12, including bug 233705.
Can we also include an optional icon value that represents the MDR? Similar to how website's can provide a favicon. http://en.wikipedia.org/wiki/Favicon
Added hours per Hubert's estimate. This may be re-assigned to JT.
So is it the idea for each datamanager/mdr to have a getDataManagerInfo service defined? (and getSoapVersion) - JT
(In reply to comment #6) > So is it the idea for each datamanager/mdr to have a getDataManagerInfo service > defined? (and getSoapVersion) > - JT Each service group will have a config file. Each COSMOS service group (data manager) will include the datamanager service. The datamanager service has two operations (getDataManagerInfo, getSoapVersion) to get these configuration values. I just want to be clear that the operations for getting the config values don't need to be implemented by each data manager.
Ok, successful test of two different Datamanagers using the same service code in the DataManager package. - JT
I have all the datamanagers/mdrs supporting getDataManagerInfo (CLI only) now but I had to change the services.xml messageReceivers for the MDRs
service finder now uses info from cosmos.properties for datamanagers. - JT
I've integrated with the changes from 235898, cosmos.properites keys that are registered by the broker are ID, DisplayName,Description, SoapNamespace, RecordTypeNamespace and SecurityNamespace. These changes are not yet checked in. - JT
Bill has added as part of 235898, the SoapNamespace to the what the broker registers, I am thinking for the new getSoapVersion() web service, that we use that to key off instead of trying to deduce it from the WSDL which may not have it (though I guess it is possible that the broker may not have it either...) - JT
cosmos.properties files have been updated to have default values for the new properties introduced by 235898, these are subject to change if more suitable default values become apparent.
The changes to the ServiceFinder are checked in, there is a bug open 241439 for the build changes that are required for this issue. - JT
Has the Example MDR been updated to contain the new config files for this enhancement?
In theory all datamanagers have been updated with cosmos.properties files. I'm still in the process of verifying work on 241439 - JT
These changes are checked in code complete, if there are bugs associated with this new bugs can be used to address those problems.
QA Review for Manual Tests/Junits: - No explicit test cases found, however this has been tested as part of End2End testing with Command Line operations uisng GetDataManagerInfo,GetDataManagerById,GetDataManagersByRecordTypeNamespace etc.
