I am adding test data using the client-toolchain,
however, the trs/base seems to be empty.
according to Copilot’s analysis:
The TRS is correctly registered and resource changes are tracked via trsEventHandler.onCreated() calls in RestDelegate. However, when server starts, RestDelegate maps are empty, so TRS initializes with zero resources. Once client-toolchain populates data via POST requests, new resources ARE added to TRS correctly. The fix is to make TRS initialization lazy or ensure it re-syncs after the maps are populated.
I am still too new to the code base to be sure if this is correct, but it looks like a reasonable assesment.
In the meantime, here’s a quick answer …
If you are familiar with TRS, there is a baseLog and and changeLog. In this case, the BaseLog is empty. All changes (via POST) will be handled in the ChangeLog.
So did my short response explain how it currently works? Copilot’s explanation is also correct. But I am not sure if the suggested changes are necessary.
It’s perfectly reasonable (for this reference implementation) that the baseLog is empty (given that the application started with an empty data base). Once resources are added to the system, they will appear in the ChangeLog.
I am quite short on time this week. Thus, replying on a phone - you may need to do extra digging.
First, I think we should avoid https://xyproblem.info/ because OSLC is non-trivial and Jazz is complicated. Those two together make for a rather challenging combo.
Thanks for the comments and support.
It maybe the deep end, but not my first rodeo (just to mix metaphors )
I am able to create a link within Jazz (RM is what I’m working with) to an external artifact from the refimpl.
I do not have GC enabled on the RM-project.
From what I have understood, I need:
RefImpl, rootservices to advertise the RM Service Provider Catalog, there is some debate as to whether the new ns open-services.net/ns/rm# is required or if the old on that is in the RefImpl.rootservices is sufficient.
RefImpl RM Service Provider Catalog must point to service provider with domain as open-services.net/ns/rm#, which I think it does.
add the RefImpl as friend in Jazz ../jts/admin
Add an Association “Uses - Requirements” in the specific Jazz Project I want links in.
This is a problem, because I cannot get the “Uses - Requirements” association offered by Jazz.
Ensure the Link Types for the project include the link type stored in the RefImpl.
In LQE admin add the RefImpl trs as a data source. I had to switch off authorisation in the RefImpl to make this work, I could not get the OAuth to be accepted by Jazz.
This is also where there is debate, as to whether the RefImpl trs/base needs to include the artifacts or not.
There are some difficulties with this process that could be made smoother
a) The I cannot switch the Jazz consumer stored in oslcOAuthStore.xml to ‘not provided’ whilst the RefImpl is running, I have to stop it change it manually, then restart.
b) mapping oslcOAuthStore.xml to a volume in docker-compose was an issue, so I changed its path to something absolute in the source code to make this possible.
c) As RefImpl does not start up with any data, I populate it with the example data from client-toolchain + my own links to my Jazz-RM artifacts for the use case I am trying to test.
have to do this everytime I restart RefImpl, I could I’m sure map something in the compose to a volume, but I do also want to be able to ‘reset’ RefImpl to no data at points, so currently easiest to do this with a restart, even if it would be nice to leave it running and have a ‘clear/reset’ endpoint to invoke.
My main issue is that Jazz-RM will not offer the Uses-Requirements endpoint, which I think is needed for it to see the external artifacts.
And I can see in the Jazz-LQE that it is not indexing the RefImpl arfitacts, which (according to Gemini) is because there is nothing in the trs/base.
From the little I can understand about trs, it is not required that things are in the base, however if they are not, then how can RM know they exist ? the RefImpl trs (changes) feed does not seem to contain all additions, it only contains the last few.
As I said before, Jazz has limitations on what kind of relations the links may have when pointing to artifacts in 3rd-party systems. Please see IBM Documentation for more information.
Let us start with that and once you confirm on your side, we will move to the next issue.
Thank you. That looks like a useful table you pointed me to.
However, the table appears to be saying that my external (RefImpl) source of requirements can only use the referencedBy link type to point to Jazz-RM artifacts!
That seems highly restrictive and I think I must have miss-understood the table !
The table is not very clear, the ‘*’ in the RM row could mean anything, or it could refer to a footnote.
Anyhow, given that the AM row clearly defines what is allowed, I will use that instead.
So using the RefImpl-AM server.
I have:
set up RefImpl-AM as a friend in Jazz/jts
added the RefImpl-AM to a bunch of whitelists in /jts/admin and /rm/admin
changed the entry added by Jazz to the refimpl oslcOAuthStore.xml to be provisional=false
Added Association ‘Provides - Requirements’ to Jazz-RM project
Tried to create a ‘Satisfied By - Architecture Element’ Link - which just hangs the browser
I discovered that Jazz was trying to access the RefImpl-AM linkType selectionDialog instead of the Resource Selection Dialog….but even after removing the linkType selection dialog from the RefImpl…I get the same Jazz-Browser page freeze.
The asterisk refers to the OSLC 2.0 and Rhapsody footnote, in my opinion.
As for the table, I think it needs to be read in the following way:
Rows represent IBM Jazz products, one per domain (DOORS NG for RM, Rhapsody for AM and so on).
The first data column represents the capabilities/limitations when linking from a Jazz tool to another Jazz tool.
The second data column represents the capability of a Jazz tool to link with a 3rd-party tool.
Thusly, the following statement:
QM artifacts can be linked to RM artifacts by using one of these link types: Validates (a requirement) Validates* (a requirement collection)
can be interpreted this way:
A Jazz QM tool (i.e. Jazz Enginering Test Management) allows the following link types linking Jazz QM and non-Jazz artifacts: validates (towards a 3rd-party OSLC RM tool, e.g. OASIS OSLC RefImpl RM).
Would you be interested in evaluating this linking capability?
P.S. I took some liberty to update titles on this thread and a number of issues for the benefit of future readers (including me).
I am currently trying to configure Jazz-RM as a consumer of links to its requirements that are stored in an external tool.
Currently, both the RefImpl-RM and RefImpl-AM are in scope (I’ll probably get to the others later).
however, I am hitting issues with both…as described above.
I am very happy to give feedback about successes and failures in all I do (so an evaluation of sorts, yes).
Especially as I am getting good help and input in return. Many thanks.
I realise I am on version 7.0.2 of Jazz currently, and I see that the latest in 7.2.0.
You link to table above is for v7.0.2, but I can’t dind the similar table in the 7.2.0 docs.
Is v7.2.0 better ? does it accept more link types?
Interesting Discovery regarding the rootservices document.
When Refimpl-RM/rootservices defines xmlns:oslc_rm="http://open-services.net/xmlns/rm/1.0/"
then when adding an Association to a project, Jazz offers both
”Provides - Requirements”
”Provides - Related Requirements”
when the oslc_rm namespaces is defined as xmlns:oslc_rm="http://open-services.net/ns/rm#"
then Jazz offers only
Jazz will most likely try to force the App (RefImpl) to store the link. RefImpl already supports this via a POST request on the resource to which you try to link. RefImpl already supports that.
If you want the link to show up from the Jazz side to RefImpl, RefImpl needs to expose the TRS feed (it does already but not in the rootservices document) and the JTS shall pick it up successfully.
Hi,
Thanks for that.
I have already, using my own version of RefImpl, fixed the 0px issue, and the AM selection dialog returning nothing.
What happens, when I select an AM resource from Jazz, is - nothing !
My goal is to create the link external to Jazz, but I’m starting with creating the link in Jazz.
I can create a ‘references’ link to a RefImpl-RM link from Jazz - if rootservices has the 1.0 namespace.
Jazz fails, silently, to create a link to a RefImpl-AM resource.
The browser i not making any relevant network calls, I am in progress trying to access the Jazz server logs.
I think the request will come to RefImpl AM not via the browser but via the Jazz backend. You may want to adjust log levels on the adaptor or even use something like GoReplay or Wireshark to confirm that Jazz server tries to connect to RefImpl.
A lot of “interesting” Jazz challenges on this thread. I have recently also had to handle similar issues against Doors NG. It’s a fair bit of guess work
What happens, when I select an AM resource from Jazz, is - nothing !
Do you see the AM selection Dialog within Jazz? (I assume it means Doors?)
If yes, does the AM Selection Dialog show some entries?
If yes, what happens when you select an item form the dialog? Can you inspect the page to see what is returned from that dialog to the parent window? (If you have gone this far, I suspect Doors does not like what i received from the dialog)
By ‘Jazz’, I mean the Jazz-RM tool (also known as DOORS-ng).
I see the selection dialog (after fixing the 0px bug)
I see resources listed in the dialog (after fixing the TODO)
I select one resource, click OK
I can see in the network tab of the browser that the correct resource is in the response
Input about the issue from Gemini (who is faster at reading the IBM docs and of things than I am, though may get confused ), indicates that maybe the returned resource-rdf maybe OSLC compliant, but not Jazz compliant. e.g. properties such as type and serviceProvider are missing. However, the lyo properties for setting these don’t seem to agree with the way they are written if I look at an example rdf from Jazz. It may even be barking up the wrong tree.
)