What are the OSLC Properties for a GC-compatible yet not GC-providing OSLC Provider for GC-enabled RM?
According to Kathryn's article, an OSLC integration developer should be able to implement an OSLC peer of Jazz DNG that is aware of Global Configuration, uses the Link Index Provider, yet is not itself a provider of Components and Streams to GC projects.
I have implemented one integration that is not at all aware of GC, one integration that is fully participating in GC as a provider of streams and components (with its own internal LDP for components, streams, and baselines), and am in the midst of developing a third integration which intends to be GC "compatible" without being a provider of components, streams, and baselines.
Therefore, I have a fairly deep and extensive awareness of how to integrate with Jazz CLM and GC.
Nevertheless, I cannot specify in my AM/DM Rootservices, ServiceProvider Catalog, and in its Services a suitable combination of OSLC properties such that the Links service in Jazz RM (6.0.4) will recognize my AM/DM Services as legitimate Link targets. The dreaded CRRRW7359W error about the Component not being part of GC Configuration is raised - unless I take the unwanted steps: of implementing an OLSC Configuration Management ServiceProvider in the rootservices, of providing the undocumented OSLC Dialogs for Baseline and for Stream selection, and of providing an initial Component with an initial Stream and Baseline - in addition to setting the documented and understandable properties for the ServiceProvider of Kathryn's article.
The goal is that a GC-aware OSLC peer can be implemented such that GC-enabled Jazz RM will allow the users to create Links from its GC/LC-constrained resources to the OSLC URIs of the peer repository.
Is there, in fact, a way that this can be accomplished? That a GC-compatible OSLC Provider can have its OSLC Selection Dialog exposed to the user within the Jazz RM app - without having to be a provider of GC Components, Streams, and Baselines?
If so, can anyone list the properties and their values which must be present in the Rootservices, Serviceprovider Catalog, ServiceProvider, and Services resources?
One answer
Lonnie, It does indeed sound like you know a lot about CLM and GC. Interesting work.
I'm not sure what issue you are having and we might need more information. I appears you are attempting to link Requirements Management (RM) and Architecture Management (AM) resources in the context of IBM's jazz.net based products. If RDNG is being used for RM, then this is a special case. RDNG expects the AM provider to provide all links, and uses OSLC query to access the incoming links then the links tab is selected for a requirement. It does this whether the project area is config enabled or not.
Given that this is the case, the AM provider need not to be config aware or confg contributing since it is storing all the links. Changing the RDNG configuration would have no impact on links. And the AM provider does not need to contribute these links to LDX for RDNG to be able to query its incoming links.
Comments
Jim, this is interesting. Are you advising that RDNG expects that the AM providers store all incoming as well as outbound links? That DNG will not store those links which originate from an RM resource? I am expecting that it will publish such links in the LDX; in fact, I'm almost certain that it does do LDX POST requests to update the LDX.
Jim,
Apparently, the issue that I ran into was https://jazz.net/jazz03/web/projects/Requirements%20Management#action=com.ibm.team.workitem.viewWorkItem&id=115412.
Because my REST controller was returning the OSLC Service resources in the format requested by the RDNG client (application/rdf+xml), they were not being accepted by RDNG and the rejection reason is entirely misleading.
By forcing a return of an application/xml resource, the Links picker for RDNG accepts the ServiceProvider as a legitimate peer and goes on to query and display the AM Provider's Services' resources as Linkable candidates.
By forcing a return of an application/xml resource, the Links picker for RDNG accepts the ServiceProvider as a legitimate peer and goes on to query and display the AM Provider's Services' resources as Linkable candidates.
I am suspecting that on the prior integration where I implemented a full LDP to offer the Components, Streams, and Baselines that I was able to get past this "red herring" by comparing the acceptable HTTP Request/Response transactions in Chrome and then altering my REST responses to match. I probably then inconveniently forgot this patch in the months between the two projects. A painful absence of long-term memory.
That was going to be my next suggestion. RDNG is expecting RDF/XML-ABBREV for the service provider catalog. Eclipse Lyo now handles this with a configuration parameter.
RDF links are directional, and OSLC does not support inverse properties, or constraints on bi-directional, covariant links. In the case of RDNG and an AM provider, RDNG expects the AM provider to store the link: resource satisfies requirement. The OSLC query RDNG uses gets these triples, and then displays them as requirement satisfiedBy resource - RDNG knows what to use for the incoming property. Only on is ever stored.