Hi all, I’m currenlty developing a microfrontend for the existing ocl subscription module. I tested the import functionality of the existing module and it throws some errors most of the time. So I’m initiating this thread to seek a solution.
Thanks so much for sharing this Piumal - many folks like @michaelbontyes have struggled with the error messages in the OCL Module, they are often not very clear user-friendly, and we have also had a few bugs with them in the past (eg OCLOMRS-1063).
CCing @suruchi & @dkayiwa as they have both worked on these errors in the recent past - might either of you have advice / insight here? Do we think some of these are even bugs?
This came up on Slack recent. See @paynejd’s comment here. Basically, you currently need to explicitly request OCL create an export before it’s available.
there’s no released version
This is because the URL you provided doesn’t specify a version in it, i.e., it just points to a collection. The module isn’t smart enough to find a version if you don’t provide one.
Thanks so so much for making this clear. I now understand why my E2E test gave a wrong output.
@ibacher just to confirm I have got you well, instead of the released dictionary manager subscription URL one has to enter the concept Id URL in the subscription url input to get the correct output?
For “released” versions of an OCL collection, we use the zip file at /<url to collection>/<version>/export/. However, OCL doesn’t create an export for the HEAD version (the version with all the changes that haven’t been released yet). To get that, the OCL module would need to ask the OCL API for all the concepts, which is effectively what the /<url to collection>/concepts/ URL provides. We make this request with a couple of parameters so that it should return all the concepts and mappings, but the layout of the JSON returned from that endpoint is a bit different from the layout of the export and we don’t have any code in the module to parse data in that format. So, even if I guessed the correct URL (and I’m guessing), it wouldn’t work.
Short version: the URL you supply to the openconceptlab module should always point to a specific version as the last part of the URL (the module will add the /export/).
This makes sense to me! Since the QA team is doing the use case testing now, my advice to leave on this particular use case is to have a specific version incorporated in the last part of the URL. for one to get the right output.