nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Scripting in Requirements Management (RM) Mapping Files

medini_1024169437

Since 2019 R2 there is another, yet unknown area where scripting becomes interesting. In that version the integration support for ALM/PLM and RM systems was improved in the way, that the rather static mapping between RM system and medini can be enriched with dynamic parts and these dynamic parts are small java script snippets.

Mappings

As you may know, a so called "mapping definition" is used when importing or exporting from a requirement management system as DOORS, PTC or Jama. The mapping definition consist of type, attribute and relation mappings in order to cope with the diversity of configurations in those systems. Each mapping typically maps a remote concept (type, attribute or relation) to a medini concept (type/metaclass, attribute or relation). The mapping is defined in an XML file:

 <typeMappings
 mediniType="SafetyRequirementsModel"
 mappedType="Requirement Document">
 <attributeMappings
 	mediniAttribute="name"
 	mappedAttribute="Document Short Title"/>
 </typeMappings>

Selectors

The mappings are fine but lack some dynamic decisions, like "ignore all requirements with ASIL < D" or "only import elements with a certain tag/term". To support that the mappings where enriched with what we call "selectors", basically an expression that has to evaluate to "true" to "select the mapping". Consequently, it is now possible to define multiple mappings, even for the same type. The connector will iterate through the mappings in order of appearance in the file and will use the first mapping that either has no selector defined or that has a selector returning "true".

 <typeMappings
 mediniType="SafetyRequirementsModel"
 mappedType="Goal Document">
 <attributeMappings
 	mediniAttribute="name"
 	mappedAttribute="Document Short Title"
 	mappedSelector="false" />
 </typeMappings>
 <typeMappings
 mediniType="SafetyRequirementsModel"
 mappedType="Requirement Document">
 <attributeMappings
 	mediniAttribute="name"
 	mappedAttribute="Document Short Title"
 	mappedSelector="true" />
 </typeMappings>

The selector expression is a Java Script snippet that is evaluated against the imported element or the exported element. In both cases the snippet may investigate the element or navigate through the model and - depending on that investigation - return true or false.

Connector Specific Selectors

Now its time to have a closer look to the selector snippets. The engine will pass the element as "element" into the snippet, so the script cod may access the attributes and relations of the object to import (a DNG or Jama item) or the exported element (a medini object). For export its easy because the API is the same as for any other script. However, for import the API depends heavily on the connector. In this article I will give some more details on the PTC Integrity connector and post some helper code and snippet. In further articles or if there is some interest, I can also post snippets for DNG and Jama

PTC Integrity

The medini integration for PTC Integrity is based on software from Sodius, a company hat is specialized in connecting tools, especially ALM/PLM tools. As a result the API is defined by Sodius in alignment with the way how PTC Integrity is build. All artifacts in PTC are basically "Items" having attribute values. The complete API is based on EMF, same as medini so the behavior is pretty much the same when it comes to access to attributes and prototypes. I prepared an initial file that can be included and used in a snippet. It provides a single function "hasAnyValue" that checks for a particular attribute in the element, and verifies that the current value is one of a given set of values. The mentioned file is attached to this article, same for the example mapping. It may evolve into a kind of library in the future.

The selector example could look like this:

 <typeMappings
 mediniType="SafetyRequirement"
 mappedType="Requirement"
 mappedSelector="load('integrity.js'); hasAnyValue(element, 'ASIL', [ 'D', 'C' ] );">

...

This selector ensures that only ASIL D and C requirements are imported, assuming that in PTC there is an attribute name "ASIL". Note the usage of ' instead of " - because the snippet itself is enclosed in " characters in the XML. Note also the "load" function call at the beginning to load the library script in front.

Last note is that the library file has to be located near the mapping file and not in the default scripting location.

Any comment is welcome!

Happy Scripting

Jan

Find more posts tagged with

medini

medini legacy

Accepted answers

medini_1024169437

Nils, Francesco ,

I think "self" is not defined, but rather "element". So each requirement is passed as "element" to the selector.

Please try

element.asil=='D'

or even better:

element.integrityLevel=='D'

because the asil attribute is deprecated.

Jan

All comments

medini_1031492114

Thanks Jan, for providing these examples!

I tried to filter my import from PTC integrity by ASIL level of the requirements, but it didn't work yet. There is no reported error. Medini just tells me, that 0 requirements are imported.

I also tried to filter my import by category/kind of the requirements. Probably medini has problems importing requirements when the parent requirement is not selected by the import.

Thanks for your support,

Franziska

medini_1024169437

Thanks Franziska for testing the approach and the library.

My idea is to extend the library by some console outputs so you can see on th console what's going on / wrong. I will post an update here later the week.

Happy Scripting

Jan

medini_1024169437

Hi Franziska,

I improved the script a little bit, you can find an updated version of it attached here.

Please change the selector to something like this:

...
 <typeMappings
 mediniType="SafetyRequirement"
 mappedType="Requirement"
 mappedSelector="load('integrity.js'); dump(element, true); hasAnyValue(element, 'ASIL', [ 'D', 'C' ] );">
...

The change is the additional "dump(element, true);" statement.

Open the java script console, import from PTC and check the debug output.

There is output like:

Connector: Integrity
 Type: Requirement
 ID: 115231
 Values: 23
 Live Item ID=115.231
 Created By=undefined
 Created Date=17.04.19 21:00

which gives general info about all attributes of an item and output like:

hasAnyValue found ASIL=D
hasAnyValue found it

which dumpy calls to "hasAnyValue".

Hope that helps to find the issue.

Happy Scripting

Jan

medini_1051428514

Hi Jan,

Can you provide snippets also for DNG?

With DNG, the upper examples run up to call the values of the element in hasAnyValue().

The element is like "com.sodius.oslc.app.dng.model.DngRequirement@44..a43"

element.values.size() didn't give the size etc.

It would be great if available example to derive value of an attribute of a DngRequirement

Thank you.

medini_1024169437

Hi!

the API for DNG is indeed differently so the PTC files will most likely not work.

Actually I was working on a similar utility for DNG but its not yet finished. I will post it anyway here so you may use it as you like. There is a similar script file "doorsng.js" and a sample mapping to show how to use it. The "EXPERIMENTAL" tag at the beginning of the script is unfortunately required because the DNG API itself is rather low level and I needed a few utilities.

Note that the example currently only dump an element with some information. There is no"hasAnyValue" function yet. You may anyhow write your own and use the existing "getProperty(requirement, name)" function.

Good luck

Jan

medini_1051428514

Thank you Jan.

getProperty works fine. It was quite helpful.

Another point is: In order to trace the updates performed in DNG, can I reach the previously imported requirements (from DNG into medini) via the javascript file (doorsng.js)? I tried to call Global or finder, however they are not in the scope of doorsng.js execution. Is there any way to reach the medini metamodels at that scope?

(The reason to do is that: if the requirement in DNG changed in a way that the new version of requirement is not within the extent of mappedselector, then the older version stays in medini. If the doorsng.js can access the medini project objects, the bi-directional custom control may be implemented.)

medini_1024169437

I think that should be feasible, though I need to check ow the object is accessible, not yet sure myself.

I will come back soon, if not, please ping me again here :-)

Regards

Jan

medini_1051428514

Hope to access the medini objects?.

Regards.

medini_1024169437

:-) Nice ping. I found out at least a little.

Just to confirm first: this time you want to export to DNG and want to access the medini requirements?

or do you want to access the medini requirements while importing from DNG?

In all cases the variable "sourceModel" and "targetModel" is defined.

During import, "targetModel" is the medini model and "sourceModel" is the DNg one.

Note that bot are wrapped by a "Facade" object, so for example a "MediniModelFacade" for the import.

There should be at least a "getAllElements()" function and a "getElement(String syncId)".

Regards

Jan

medini_1051428514

I dealt with importing requirements until now.

getAllElements() gives the medini model in an object as LinkedHashSet class. For those interested:

var allelements = targetModel.getAllElements();
var itr = allelements.iterator();
var mymodel = itr.next();

Then, the mymodel behaves like a medini object SafetyRequirementsModel.

Thank you Jan.

Best regards.

Ayhan.

medini_1024169437

Glad it works!

Jan

medini_1051428514

Dear Jan,

I am trying to get the hierarchy information of a DNG requirement while importing into Medini. It is given in the value "section" or "depth" information of the requirements. They are neither an attribute nor a link, therefore, they cannot be obtained via getProperty(element,'Section').

However, as I understand, the Medini can get those values via other ways, please correct me if i am wrong. The target model is created in the same hierarchy:

How to get the subrequirements of an element in sourceModel while importing? Or is there any function defined in DngAPI to get section or depth or hierarchy information?

medini_1024169437

The "No" column is indeed currently not reachable via script, its not an attribute or operation. A pity I would say.

Sub-requirements in medini are accessed via the "subRequirements" relation. From model to top level requirements its the "requirements" elation.

Anyway, the algorithm for "No" columns doe sit anyway differently, it navigates upwards from each element, you can do that with ".mediniGetContainer()"

Each step upwards introduced a new counter and "." separator.

Hope tat gives you some ideas.

Jan

medini_1051428514

The req1.mediniGetContainer() works when the req1 belongs to medini safetygoals metamodel package.

However I am trying to the get the container of a DNG (requirement) element in the sourceModel while importing.

The element has class com.sodius.oslc.app.dng.model.DngRequirement

While importing:

var myelement = sourceModel.getAllElements().get(0);
console.log(myelement.getClass()); 
// com.sodius.oslc.app.dng.model.DngRequirement

//then the followings are actually not for this type of element
var myupperreq = myelement.getMediniContainer();
// or
var myupperreq = myelement.container;

I think the medini actually get those information, because the targetModel is created in the same hierarchy of Doors NG. (By the way, to read containers from medini metamodels (targetModel) creates problem when the first time of importing. That is actually not a desired way for our case)

medini_1024169437

Navigating through the DNG side is more complicated since its not backed by an EMF model but still pure OSLC stuff. There is no API to directly navigate from an object to its parent or its children. You have to use the passed "ModelFacade" I mentioned above, so "sourceModel" or "targetModel". You can use the "Requirement Facade.getParent(requirement)" method to navigate up.

Happy Scripting

Jan

medini_1024169437

There has been recently the question on "how to set the ASIL to None if a DNG requirement is not safety related and doe snot even have an attribute to map". Well, for those cases you probably need two type mappings, one for safety related DNG objects (having an ASIL attribute themselves which you can map) and a second one that is used for anything else. Tricky is to though set a value "None" to the requirement ASIL because medini's default is "ASIL D".

I attached a sample mapping in which I solved the problem by mapping the "InstanceShape" attribute to the ASIL. Sounds weird but in principle medini does not care, we simply use it but could use any other attribute. Note that the example just illustrate how to do it with a single example (Heading) but you can extend it to other instance shapes easily.

The key line is this:

<attributeMappings
 mediniAttribute="asil"
 mappedAttribute="InstanceShape">
 <valueMappings
 mediniValue="None"
 mappedValue="Heading"/>
</attributeMappings>

Happy Scripting

Jan

medini_1059817781

In last discussions with you it was recommended to use the following when creating links in medini that are not trace links:

The above code doesn't appear to do anything or I don't know how to see it? I have dragged 2 rqmt elements to a diagram to see if they get auto-created, but nothing happens. Where can i see whether this imported and got created correctly?

instead of create actual trace links in medini when importing from DNG, which was working:

medini_1024169437

Hi Michele,

so you basically say, that it was working with "Trace" and you saw the Trace on the diagram but when you switch to "Contribution" you do not see them?

Two ideas:

Have you checked "Related Elements --> Contributes To" menu? Maybe its a diagram issue
Are both requirements in the same module?

Regards

Jan

medini_1059817781

Yes, that is correct. I can see the trace relations (they were different modules) and No I cannot see the Contributes To relationships (they were in the same module)

Yes. Both are in the Same Module.

I also noted if I use the Trace relation setting and the traced are within the SAME module, it does not import them

The Related Elements --> Contributes To is grayed out

medini_1059817781

Contribution link didn't show up when in separate modules either.

medini_1024169437

Hello Michele,

on your picture I see actually two relations between the requirements, the dotted one (1) is the trace and the solid on with an arrow (2) is a contribution relation:

So I think it is there, isn't it?

Regards Jan

medini_1059817781

Here is what I have tested:

Scenario 1: Module that has links internal and external to itself.

Result: The Contribution links import correctly. See below -- I removed the trace relation from the mapping file and only left the Contribution relationship mapping)

After testing and reviewing the other Module test that was not working, the issue with links not importing are links to BASE artifacts, which do not get imported into Medini. Only links to artifacts inside another Module are imported.

All Good now.

Question: Would I be able to perform a links check in the script file and then stop the import if links are created improperly? (i.e., to the base and not to an artifact inside a module? At least this way I can output something to console perhaps for the user to go fix prior to importing and then trying to do the research.

medini_1024169437

Michele,

there are a few options here, Ayhan TÜRK had similar questions in this article. He wanted to observe the target model (the medini module) while importing. Though the possibilities are limited in the sense that we have to use more advanced scripting. Could you tell what BASE exactly is in your case?

Happy Scripting

Jan

medini_1059817781

Jan:

Sorry for the delay. A BASE artifact in DNG is one that gets referenced if it also exists inside a Module. The Base URL is different then the URL of the artifact while it is in a Module, or multi-modules. Its Reuse of the same BASE artifact in multiple locations. If you change it at the base it changes in all locations. There is the ability to create links to all locations and the linking is associated with location, i.e., inside a specific or multiple modules or not.

medini_1024169437

Huh, that definitely goes beyond my DNG horizon. However, I can confirm that it should be feasible to check the target model and prevent individual requirements from being imported, you cannot stop the while import with an error message or something.

Jan

medini_1051049827

I came across the problem, that
if a requirements module contains safety goals and safety requirements the synchronization
from DNG to medini does not work properly. This is caused by the fact that the
mapping is not deterministic. There is only DngRequirement but this must be
sorted back into safety goals and safety requirements.

This can be achieved with a
selector for both mappings for the mapped type. For this a dedicated attribute
or artefact types must be used for safety requirements and safety goals in DNG
which can be evaluated. Writing them when exporting from medini to DNG is
straight forward.

When pulling back into medini,
the attribute or artefact type must
be evaluated by the 'mappedSelector' in a kind of a filter for the mapping
definition.

The
filter function can be defined within the selector script doorsng.js, i.e. the
shape function as in the example. This can be adjusted as required.

The
advantage is, that one can use one mapping file for all and does not need to
choose a dedicated one for the prototype.

medini_1024169437

Thanks Nils, highly appreciated. I am sure, other users can benefit from your posedt files.

Happy Scripting

Jan

medini_1063115319

HI Nils Kadelka,

I tried to import requirements from DOORS-NG into Medini using your attached Mapping file. But following error occurs.

Can you guide me how I can counter these errors.

Regards,

Danish Ghaffar

medini_1024169437

Hi Danish,

I think that missing attributes were added by Nils to the medini side, so to safety goals and safety requirements,

you basically need to do the same. Note that meanwhile custom profile properties start with user_.

The type of the profile property you need to derive from the mapping file and your counterpart on DNG side I think.

You maybe cannot use it out of the box.

Regards Jan

medini_1056378978

Dear Nils and Jan,

Thank you so much for the helpful information!

Recently I have struggled for exporting SG from Medini to DNG for a long time, and cannot make it. After trying your useful DNG_selector_example.mapping and doorsng.js, I can finally success to export ESL SG to DNG but only one SG is export onto DNG. However, when I continuously click push changes, the wrong server setting error happened.

Medini package I want to export Only one SG exported to DNG Error after clicking push changes to DNG

The attached mapping file is the one I modified a little bit according to my DNG setting, and I didn't revise the js file you provided. Could you guide me how to fix this issue? Thank you!

BTW, I'm using Medini 2020R2 version and DNG 7.0.1 version. The 2021R1 version cannot exchange requirements between Medini and DNG totally.

Best regards,

Sara