[OSLC] How to query the hierarchy of requirements within a module
Hi,
Accepted answer
Hi Davyd,
Comments
Integrations are complex and always will be complex. They are expensive and greatly desired, but usually no one wants to pay for them. Everyone has different opinions about what an integration between tool A and B should do. Creating, maintaining and documenting public APIs costs money and effort that are taken away from features that users request. I would personally like to have all APIS being public and documented, but unfortunately the reality is different.
The language that is used to develop a tool, has nothing to do with APIs being available. OSLC is also not a solution for everything. E.g. there would not be a need for a module API, if OSLC would have a module API. Eclipse Lyo is not the solution for everything. It has complexities that actually make it hard to use for certain things. I have switched from Java Lyo to Python, because it is way easier for me to track request and response contents. In Lyo I always struggled to be able to see what goes back and forth. You would need to use Fiddler or similar software.
Apologies for the typo! Yes DOORSRP-Request-Type: public 2.0 is the correct header.
@Ian No worries. I'm glad we could sort it out.
Eike,
Note that DNG has a ton of internal APIs that are not documented, not supposed to be used, but absolutely essential if one needs certain functions. The Module API is published. See https://jazz.net/wiki/bin/view/Deployment/CLMProductAPILanding , but others are not. I think there is no module concept in OSLC RM as a standard it usually is only a subset.
Hi Ralph,
Hi Eike,
I am just unhappy with the API situation for quite some time. The OSLC Workshop is absolutely something that should be updated. Rosy has updated it at some point. I have considered updating it as well, but that required me to look into OSLC more and create examples. I have struggled with RDF XML for so long that I preferred other APIs. But I made progress now and I try to get there.
3 other answers
Hi Eike
- Don't use header OSLC-Core-Version
- Use the header:DOORSRP-Request-Type: public 2.0 - capitalized exactly as I've put here
- Provide the configuration using header vvc.configuration - only accepts a local configuration
Hi Ian,
private static void processModuleDescription(Map<String, IRMRequirement> requirements, DocumentBuilder builder, RMModule module, ClientResponse response)
{
try (InputStream input = response.getEntity(InputStream.class))
{
Document document = builder.parse(input);
Element root = document.getDocumentElement();
NodeList contextBindings = root.getElementsByTagName("rrm:contextBinding");
for (int i = 0, length = contextBindings.getLength(); i < length; i++)
{
Node contextBinding = contextBindings.item(i);
Map<String, String> properties = getXMLProperties(contextBinding);
String section = properties.get("rrm:section");
int depth = Integer.parseInt(properties.get("rrm:depth"));
int bookOrder = Integer.parseInt(properties.get("rrm:bookOrder"));
boolean heading = Boolean.parseBoolean(properties.get("rrm:isHeading"));
String identifier = properties.get("rrm:identifier");
RMRequirement requirement = (RMRequirement)requirements.get(identifier);
RMModuleRequirement parentRequirement = getParentRequirement(module, section, depth);
RMModuleRequirement moduleRequirement = new RMModuleRequirement(requirement, module, parentRequirement, section, depth, bookOrder, heading);
if (parentRequirement == null)
{
module.addSubRequirement(moduleRequirement);
}
else
{
parentRequirement.addSubRequirement(moduleRequirement);
}
}
}
catch (IOException | SAXException ex)
{
throw WrappedException.wrap(ex);
}
}
private static RMModuleRequirement getParentRequirement(RMModule module, String section, int depth)
{
RMModuleRequirement parent = null;
StringTokenizer tokenizer = new StringTokenizer(section, ".");
for (int i = 0, parents = depth - 1; i < parents; i++)
{
int segment = Integer.parseInt(tokenizer.nextToken()) - 1;
IRMModuleRequirement[] subRequirements = parent == null ? module.getSubRequirements() : parent.getSubRequirements();
parent = (RMModuleRequirement)subRequirements[segment];
}
return parent;
}
It turns out that the "/rm/publish/modules" approach does not work for us because we'll need to update the module structure later.
Comments
Fropm memory I thought the oslc_rm:uses tags are the references to the artefacts being used in the module, so you unpack those to get to the actual requirements
Thank you for you reply. What you say is correct, but it does not answer my question. I know how to access to actual requirements that are bound in the module. I asked how to access (read and modify) the module bindings of these requirements, i.e., their structure within the module.
Also when accessing the Module API:
- Don't use header OSLC-Core-Version
- Use the header:DOORSRP-Request-Type: public 2.0 - capitalized exactly as I've put here
- Provide the configuration using header vvc.configuration - only accepts a local configuration