Community
Participate
Working Groups
In i10, when deregistering all items and relationships of an MDR at test federating CMDB, the UI first queries the MDR for a list of items and relationships, and form a deregister request with this set of items and relationships. I think the logic is incorrect. We cannot assume the data at the MDR and federating CMDB are synchronized. That is, the number of items/relationships a the MDR may be more or less than what is registered. If you form the deregister request by getting the item list from the MDR, there is a chance that you are not deregistering all items or relationships. The correct way is not do query the MDR at all, but to form a query to deregister all items or relationships with a given MDR ID. In i9, the code used the asterisk '*' character to denote "any" in the localId field. I don't think it is part of the standard. So we need to find out if the CMDBf spec allow us to express the request of deleting all items/relationships given the mdrId only. (Both mdrId and localId are mandatory elements under instanceId.) For reference, the deregister request in i9 looked something like this: <deregisterRequest xmlns="http://cmdbf.org/schema/1-0-0/datamodel"> <mdrId>org.eclipse.cosmos.samples.cmdbf.XMLRepository</mdrId> <itemIdList> <instanceId> <mdrId>org.eclipse.cosmos.samples.cmdbf.XMLRepository</mdrId> <localId>*</localId> </instanceId> </itemIdList> <relationshipIdList> <instanceId> <mdrId>org.eclipse.cosmos.samples.cmdbf.XMLRepository</mdrId> <localId>*</localId> </instanceId> </relationshipIdList> </deregisterRequest>
Changed the logic to loop through list of mdrs and then check the mdrid against the mdr of the CIs registered in the CMDBf. The matching CIs are then deregistered.
Leonard, I have looked at your fix for this bug, which I assume to be in the following file only: org.eclipse.cosmos.dr.drs.service.handler\src\org\eclipse\cosmos\internal\dr\drs\service\outputter\StatusResponseOutputter.java The logic for doing deregistion used is as follows: 1. get the MDR ID 2. query the federating CMDB with the following query, and substitute %s with the MDR ID got in step 1: <?xml version=\"1.0\" encoding=\"UTF-8\"?> <s:query xmlns:s=\"http://cmdbf.org/schema/1-0-0/datamodel\"> <s:itemTemplate id=\"%s\"> </s:itemTemplate> <s:relationshipTemplate id=\"all-relationships\"> <s:sourceTemplate ref=\"%s\"/> <s:targetTemplate ref=\"%s\"/> </s:relationshipTemplate> </s:query> 3. Deregister items and relationships returned from the query in step 2. Let's take a close look at the query used in step 2. No matter what you substitute in %s, the result will be the same. The template id won't affect the query result. The query will return "all items that have a relationship with any item". This query does not do the work of getting items by MDR ID, and I don't see extra logic for sorting through the query response for items/relationships that have the MDR ID got in step 1. In fact I verified my analysis above with the i11 candidate build. Here are the steps: 1. register all items of the example MDR (Sample Repository with Query) with the federating CMDB (Sample Repository with Registration) 2. register all items of the SML MDR (Resource Repository) with the federating CMDB (Sample Repository with Regisration) 3. Query the federating CMDB (Sample Repository with Regisration) with the following query: <?xml version="1.0" encoding="UTF-8"?> <s:query xmlns:s="http://cmdbf.org/schema/1-0-0/datamodel"> <s:itemTemplate id="all-items"> </s:itemTemplate> <s:relationshipTemplate id="all-relationships"> <s:sourceTemplate ref="all-items"/> <s:targetTemplate ref="all-items"/> </s:relationshipTemplate> </s:query> ==> You will see items and relationships from both MDRs from the query response. 4. Deregister all items from the example MDR only from the federating CMDB. 5. Refresh the query response of the query in step 3. ==> I expect to see items and relationship of the SML MDR because I only deregistered items from the example MDR. However, the response is empty. That means all items and relationships are deregistered. I am raiing the severity to major because it's a wrong behavior.
I talked to hubert and we agreed to use the following query. <?xml version=\"1.0\" encoding=\"UTF-8\"?> <s:query xmlns:s=\"http://cmdbf.org/schema/1-0-0/datamodel\"> <s:itemTemplate id=\"test\" suppressFromResult=\"false\" > <s:instanceIdConstraint > <s:instanceId> <s:mdrId>%s</s:mdrId> <s:localId>*</s:localId> </s:instanceId> </s:instanceIdConstraint> </s:itemTemplate> </s:query> Note that I use a "*" character as a wild card for the localid. I also subsitute the mdrid at runtime. For some reason I didn't have to create a relationshipTemplate. The relationships were deregistered once I deregistered the items. Hubert, is this expected?
Query for getting all CIs from a given MDR ID: <?xml version=\"1.0\" encoding=\"UTF-8\"?><s:query xmlns:s=\"http://cmdbf.org/schema/1-0-0/datamodel\"> <s:itemTemplate id=\"items\" suppressFromResult=\"false\" > <s:instanceIdConstraint> <s:instanceId> <s:mdrId>%s</s:mdrId> <s:localId>*</s:localId> </s:instanceId> </s:instanceIdConstraint> </s:itemTemplate> <s:itemTemplate id=\"itemswithrel\" suppressFromResult=\"false\" > <s:instanceIdConstraint> <s:instanceId> <s:mdrId>%s</s:mdrId> <s:localId>*</s:localId> </s:instanceId> </s:instanceIdConstraint> </s:itemTemplate> <s:relationshipTemplate id=\"relationship\"> <s:sourceTemplate ref=\"itemswithrel\"/> <s:targetTemplate ref=\"itemswithrel\"/> </s:relationshipTemplate></s:query>
close bug
