OSLC AM links with Polarion & TRS

OSLC implementations
1

Hello,

I’m having issues figuring out the right way to implement links.
I implemented an OSLC AM provider and I’m doing some tests with Polarion.

For now I can link requirements to my AM resources (I don’t know how Polarion store this information).
On the AM side, I would just store the URI of the requirement in the corresponding AM resource (without using OSLC AM model)
I saw that there is a linkType Resource, should I create a linkType Resource for each links ?
linkType Resource does not specify a “source” and “target” for the link, should I add theses properties ?
Are the links meant to be bidirectional ? Like if I create a link in Polarion, should I create the opposite in my AM resource ?

About tracked resource set, I’m not sure how it is used. Is the goal to regroup resource by a criteria ?

I hope my questions are somehow understandable.

2

I may not be answering the right question, but will take a stab at it. If I understand the in-work 3.0 link guidance, the “source” is the Subject (link initiator) and the “target” is the Object with the link type being the Predicate. The guidance also states that links should only exist once, so they’re not bidirectional. In fact, section 2.1.3 (Store link information in once place) goes into some good detail about why you don’ t want that. Hope that helps some.

3

I believe by LinkType you are referring to is OSLC Architecture Management Version 3.0. Part 3: Constraints. This seems to have a different intention than what you are trying to do. And, indeed it does not have source/target properties (again, because it is meant to be used to define types of links. and not links themselves).

But from the AM:resource (OSLC Architecture Management Version 3.0. Part 3: Constraints) have you considered using any of the already defined properties such as jazz_am:refine, jazz_am:elaborates, `jazz_am:trace, etc.

These seem to me to be where you might want to store the link back to the Polarion requirement.

Otherwise, it also seems to me that there is some confusion between how to store links to other resources and how to expose them when sharing an OSLC resource.

How to store them should be completely up to your application. The above tips relate to how to share the link to the Requirement from the AM resource,

Finally, agree with Jim that links should only exist once, so they’re not bidirectional. So, if Polarion creates a link to your AM resource, you should avoid having that Link handled from the AM resource.
Having said that, I do also know that Polarion sends a PUT request to your AM provider with the created link so that you can update the AM resource accordingly. (But I normally ignore handling the request. There are no expectations to update the target resource)

4

Bidirectional links are essentially links without semantic directionality. For example, you might say change request A --relatedTo–> change request B, or change request B --relatedTo–> changeRequest A, and they semantically mean the same thing. For reporting on bidirectional links, you usually query both directions.

On the subject of Tracked Resource Set, I recommend you read Tracked Resource Set 1.0 Primer as it explains usage with examples, and is much easier to get started with than the normative spec itself.

5

Hi @Michael.C

Below are some opinions based on more than a few OSLC implementations we’ve done at SodiusWillert.

Since you are targeting Polarion, I would have a different take on this.

  1. Polarion does not support global configuration, so pretty much like in ELM: if you are not in GC context, you are totally right creating links AND backlinks. Polarion does not support link discovery, so you are not expected to create a TRS feed to help in that area. It will not.
  2. Polarion does not provide support for TRS. If you were into reporting rather than just linking, I would recommend looking at the reporting features in the latest Polarion releases that provide some support for doing reporting over OSLC links available in Polarion. They have link appearance like we do in OSLC Connect for Jira, as well as Tables. We’ve built a help desk for our customers and more with pretty good knowledge about OSLC tools usage (and obviously how all of that goes with our implementations!). You can read our Siemens administration specific articles at Siemens Tools. This is a work in progress help desk, it’s growing every other week, so you can also check back from time to time.

Hope that will help :slight_smile:

1 Like
6

Hello everyone,

Thanks for all the replies and sorry for my late answer. I needed time to digest everything.
Concerning global configuration, I will have to implement it but I’m trying to make things work without it at first. I’m not sure about TRS yet as I need to understand more things about OSLC.

So, all the information was really useful. I’m now using the jazz_am for the types of links.
Also, I handled the put request from Polarion and created a back link.

Afterwards, I tried my implementation against DOORS next. It’s not working as expected. I found out that DOORS is using link discovery to find already existing links on the am side (I guess it parses all the resources inside my resource provider and tries to find some relevant links). I cheated and programmatically created a link to DOORS on the am, and it’s showing in DOORS (I have duplicate but that is not my main issue yet).
I now understand why backlinks are not necessary.

I don’t have an OSLC consumer yet, so I can’t use link discovery on my am yet, also I need the links to be created from the DOORS interface.
So I wonder if it’s possible to configure DOORS to send a put request to my provider when I try to create the link from DOORS.

From what I can see from the logs, after I try to create a link from doors like implemented_by. DOORS is performing 2 oslc query. The first one with something like dcterms:references in [] and a 2st one with *=.
What is the purpose of these requests ? Is it only to verify that the link already exists on the am side ? Should I create my link after the queries ?

Thanks again for the advice.

1 Like
7

Hi,
I know this is a 4 year old thread now, but I came across it.
I am trying to integrate my own OSLC AM server with Polarion.
I have manage to get Polarion to talk to an RM server, but not the AM one.

when I try to ‘Add Association’ from Polarion to my AM server, Polarion says

No supported OSCL service provider catalog found in root services document.

As far as I can tell, the rootservices document is correct, it is the same format as the RM one, but obviously with AM namespaces instead of RM namespaces.

Any ideas ?
many thanks

8

@dhakehurst there may be some extra config you need to do on the Polarion side to enable links beyond CM: Polarion OSLC Services for your Configuration

@jad do you recall?

9

Hi,
Thanks for the link, but I have configured all that already, and added the am namespace (not mentioned in the post you linked).

The problem seems to be earlier than that though. Polarion is not recognising the rootservices and service provider info that is output from the RefImpl-AM.

Polarion seems to be looking for something that is not in the RefImpl service discovery info.

I can’t find out what it is looking for (nothing in the Polarion logs), and the RefImpl-AM info seems to be identical to the RefImpl-RM info (other than the obviouse RM/AM difference).
Polarion recognises the RefImpl-RM services.

10

Hi

It’s tricky working against a black box (polarion), since you have to guess what Polarion is looking for.

My guess is that the AM domain is not defined in the polarion configuration (see admin sections under Linked Data Semantics, Linked Data Mappings) at either the global or project-specific configuration.

But if you have RM working, you have a good starting point.

I’d make AM rootservices/catalog look the same as RM, and work backwards from that until Polarion stops working (then you can tell what Polarion expects :-))

11

Now that you are looking into Polarion, one of the old issues you reported and I dismissed w.r.t. Jazz - the use of OSLC v1 namespace URIs - could be relevant again. Polarion implements OSLC in a more standards-compliant manner and it could be possible that it only looks for the v2-namespaced domain declarations. If you need both Jazz and Polarion support on the same adaptor, it could make sense to extend the root services document to state that the SPC may contain:

  • SPs for the RM v1 domain
  • SPs for the RM v2 domain
  • SPs for the CM v1 domain
  • SPs for the CM v2 domain
  • SPs for the AM v1 domain
  • SPs for the AM v2 domain
  • SPs for the QM v1 domain
  • SPs for the QM v2 domain

A bit annoying but I would give it a try.

12

you got me thinking @andrew

have a look at Polarion’s own rootservices. it should tell you what it expects (you can connect polarion to itself or other polarions)

https://your.domain.com/polarion/oslc/rootservices

13

I tried that already, and made sure it looks the same :slight_smile:
did not help :frowning:

14

I have tried both v1 and v2 namespaces already, for AM, neither seem to work

15

other than the AM/RM namespace difference, the rootservices/catalog look the same (already checked that).
Polarion does not ‘out-the-box’ support am. I have added all the necessary bit in their Linked Data Semantics, Linked Data Mappings, as per the other domains CM/RM.

16

I am not sure how (w.r.t. root services document), but Obeo achieved an OSLC AM interop with Polarion in their Perseus tool: https://www.obeosoft.com/download/release/publication-for-capella/2024.5/2024.5.2/Perseus%20-%20Polarion%20Config.pdf - please make sure your setup in Polarion corresponds to the steps from the guide on pp. 6-7:

Configuring Linked Data Semantics for OSLC AM in Polarion

To enable linking between Polarion Requirements (OSLC RM) and external Architecture resources (OSLC AM), configure the Linked Data Semantics as follows.

1. Add the OSLC AM Namespace

In the <namespaces> section of your configuration, add the OSLC Architecture Management (AM) namespace:

<namespaces>
    ...
    <namespace prefix="oslc_am" url="http://open-services.net/ns/am#"/>
</namespaces>

2. Register the OSLC AM Domain

In the <domains> section, register the OSLC AM domain and define its resource type:

<domains>
    ...
    <domain prefix="oslc_am">
        <resourceType label="Architecture Resource" uri="oslc_am:Resource"/>
    </domain>
</domains>

3. Configure Link Types

In the <linking> section, define the links you want to make available between Requirements and Architecture resources.

Example:

<linking>
    ...
    <link name="oslc_rm:specifiedBy" reverse="oslc_rm:specifies">
        <from type="oslc_rm:Requirement"/>
        <to type="oslc_am:Resource"/>
    </link>
</linking>

4. Save the Configuration

After making the changes, save the configuration.

Notes

  • The from and to elements define the allowed source and target resource types.
  • The reverse attribute defines the inverse relationship shown on the target resource.
  • Additional link types can be added following the same pattern, depending on your integration needs.
17

Thank you very much for that detailed description of the set up.
I had actually done all of that, except I had the link specified the other way around.

Sadly, even after changing it to the above, I still get

No supported OSCL service provider catalog found in root services document.

when I try to ‘Add Association’ !

It looks like Polarion is expecting something different to what is supplied by the RefImpl-AM. But it does no tell me what it wants different, grrr - the frustration of error messages with insufficient information!