This one is particularly applicable if you are using the Rhapsody Profile Builder but the underlying cause may hit you in other areas of modeling too. 

The Profile Builder uses a domain specific language to model different aspects of profiling in order to generate the lengthy textual files Rhapsody uses. One of these is generating property files. To achive that is uses nested new terms based on Class, mirroring the Rhapsody property structure: Subject, Metaclass and Property.

The problem is if you are modeling a profile for Rhapsody in C then you are likely using RiC and have created a RiC project. Rhapsody will not allow you to add a 'class' to another 'class' in such a project and so when you add a Subject - you get no Add New menu for it despite the Subject term having its own custom Add New Menu definition - Rhapsody cheerfully ignores that and decides that since you have no applicable model elements to add, it will hide the Add New Menu.

The solutions:

1. Use RiC++ to build the profile (the profile itself can be C by changing the language)

2. If you are using C then temporarily change the project language to C++

3. Avoid the Rhapsody Add New Menu altogether - the Rhapsody Power Pack has an Add Model Element helper which is far easier to use than that menu anyway.

I had a very interesting situation this week regarding the use of custom profiles that define their own Add New Menu. In this case I was using the Profile Builder to update an AUTOSAR profile. I added a new term called Subject and then tried to add a Metaclass to it, but no Add New Menu showed up at all. It showed up in every other model - just not this one. My buddy Ryan in IBM found the root cause - the model language was C whilst the language of the profile was the default C++.

Now this is of course a defect - the language of the Units in the model should have no effect at all on the Add New Menu and I'm sure IBM will fix it but in the meantime, if this happens to you, here are two workarounds:

1. Change the Project Language

Temporarily of course!

1. Right click the project and select Edit Unit

2. Change the language to C++ (answer NO when asked if you also want to change the language of all sub-units)

Then you get your Add New Menu back. Once you've added one of your New Terms you can always add another one easily later without the Add New Menu by clicking the category (curiously the defect also removes the 'add another one of these' menu on the artifact itelf as well as its keyboard shortcut (Insert)

3. Once you've added one element - change the language back.

2. Use the Power Pack

I stopped using the Add New Menu a while back anyway - it got frustrating trying to find the right sub menu for an artifact and also profiles like SysML completely hijack the Add New Menu and obfuscate anything else when trying to add elements to a base term like Package.

Which is why I added the Add New Model Element helper to the Power Pack. You can launch it from any element at all using a helper menu - or if you are lucky enough to be on Rhapsody 10+ already then you can use a keybaord shortcut to launch it which is even more convenient. Then you can simply type a few characters, hit Ctrl-Space and add whatever you need - its a huundred times faster than the clunky Add New Menu:

I experienced quite a few crashes when using the Rhapsody API but they were for the most part non-deterministic. After enabling windows crash dumps I was finally able to track down the cause. 

You may be using another virtualization engine but will likely experience the same issues baecause the root cause isn't the Virtual Machine but the ARM64 version of windows thats running on it. Windows runs x64 apps on ARM64 using a compatibility layer called WOW64 that (amongst other things) redirects system calls. Because Rhapsody is not a native ARM64 application, its running on a hybrid mixed ARM64EC/AMD64 process.

When vc_redist64.exe runs (that is the Microsoft redistributable libararies that Rhapsody requires) on ARM Windows it installs the ARM64EC flavoured mfc140.dll into System32 instead of the pure x64 version. Rhapsody then loads the wrong flavour and some processes are not initialised correctly - resulting in Rhapsody crashes. Its indeterminate becauser the intialization is affected by threading and timing differences. 

The fix (at least for me) was a simple one - install Rhapsody on an Intel machine and then copy the following dlls from that machine (from the Windows System32 folder) into the Rhapsody folder on Parallels. Windows DLL search order will prefer the local copy over System32 - and hey presto - far fewer Rhapsody crashes.

• mfc140.dll
• mfc140u.dll
• mfcm140.dll
• mfcm140u.dll

If you try to add a model element (or rename a model element) and another model element of the same underlying type exists anywhere else in the model, Rhapsody displays a warning. For example if you have a Block named B in a package and you try to add another Block (or an Interface Block, Flow Specification and so on which have the same underlying type) into another package with the name B then Rhapsody displays a warning:

Whilst this is very useful - it can be disabled by setting the following property at project level:

General.Model.WarnForDuplicates

Note that in some older versions of Rhapsody, trying to add a new model element (with a duplicate name) via the API without this property set would fail badly - since there is no way for the API to respond to a warning dialog! Thankfully in more recent versions this is not the case adding elements with duplicate names through the API ignores that property and adds them anyway.

When obtaining information from Rhapsody properties through the API, the IRPApplication class has a very useful function:

This will automatically replce any $keywords such as $OMROOT with their real values. 

But this also expands any system environment variable, or even custom variables you add to your Rhapsody.ini file! 

For example:

Another variable which may be of use that is not in the environment variables but is built into Windows is $USERNAME which Rhapsody expands to your windows user name.

As you may already be aware you can call java plugin methods from within context patterns, for example:

{uc}pluginMethod:getUseCases

But you may not know that you can qualify that with a specific plugin. Doing so has two advantages:

1. Performance. If you don't qualify it then Rhapsody looks in every currently loaded plugin for a public method with that name. If you qualify it then Rhapsody only has to check that plugin.
2. Name Clashes. If another loaded plugin has a public method with the same name as the one you want to call its a crapshoot - Rhapsody will use the first one it finds.

Qualifying Method Calls

To qualify the method simply prefix the method with the name of the plugin and a colon. That is the name of the plugin from the HEP file that loads it (not the java class name). For example:

{uc}pluginMethod:MyPlugin:getUseCases

WebView2 is a control provided by Microsoft that allows applications to embed web technologies into their apps (it uses Microsoft Edge as the rendering engine).

https://learn.microsoft.com/en-us/microsoft-edge/webview2/

Historically Rhapsody used an embedded Internet Explorer whenever it needed to display web content (such as the Welcome Page or a login page for RMM). Starting in version 10 it has now switched to using WebView2. 

Why Does it Matter ? 

For the most part it shouldn't - you won't even notice it unless you are looking in the task manager and you're wondering what all these WebView2 Manager processes are. WebView2 is installed by default on Windows 11 but if you are using an earlier version or Windows Server then it isn't and you'll usually need to download it from Microsoft because Rhapsody doesn't ship it. And thats when it might matter - if you download it yourself then it may not be the version Rhapsody expects and this can cause crashes whenever Rhapsody needs to display a web page, which is more often than you think. Even Help > About is a web page !

By default Rhapsody displays the Welcome Page whenever you launch the appication - which if you have a WebView2 problem may cause Rhapsody to crash instantly (you can stop that by changing the setting in your ini file: SHOW_WIZARD_AT_STARTUP=FALSE). 

If you have a problem with web page content not showing up or crashing Rhapsody - contact IBM Support ! 

Views and Viewpoints are part of the SysML Profile and on the surface they seem kind of pointless since they don't do anything - or do they?

Did you know you can use a Viewpoint in a query? (Which can then be used in tables or to filter the model browser / diagrams). Queries (and table layouts since the dialog is unified) have a field for Viewpoints:

Constructing Viewpoints

To create a Viewpoint simply add one in the model (either in a package or in a View which is nothing more than a new term based on package) and then add the elements that conform to it using a <<conform>> dependency:

You can have as many <<conform>> dependencies as you want. The query result then returns any element that conforms to the viewpoint, and all of its children, and the viewpoint and any of the <<conform>> dependencies. 

You can also use a stereotype instead of / in addition to regular model elements.Which is great for your own stereotypes but no so great for predefined ones like <<Block>> which are read-only (in fact this entire mechanism really should have been implemented the other way around - so viewpoints are a perspective on the model without having to change the model elements themselves). 

Any elements that have that stereotype will be then be included in the query result (along with their children) and the stereotype. And because of the way that Rhapsody displays elements in the browser - all of their parents as well:

So Viewpoints are not totally useless but you have to modify the model elements in the viewpoint to use them and they do include elements you may not want to see. The Model Visualizer in my Power Pack solves both of those problems by having a Visualization point at the elements you want to include (the Scope) along with filters - which can be simple type lists or queries and supports black / whitelists (so either 'include everything but this' or 'only include this'). Because it uses queries you can use any query feature supported by Rhapsody such as 'has a tag with this value')

You can then launch a dynamic visualization engine to browse the filtered model (and of course you can navigate back to Rhapsody from any node in the graph):

When Rhapsody loads profiles it also loads any property files at that time. If a property is defined more than once (which may happen when you have multiple profiles) then there is a race condition - and there is no way to determine which property file will 'win' and which value will be used.

Conditional Properties

Conditional properties are extremely powerful in Rhapsody and allow properties to take their values from other properties (or even the rhapsody ini, environment variables and other sources).

Conditional properties may include an instruction to Rhapsody to look in all currently loaded profiles for a named property and combine all of their values into one - thereby avoiding the race condition (so long as all of the profiles use the same base conditional property) 

The syntax is simply to prefix the original property key with Profiles:: and then Rhapsody will look in all profiles for a property with that name and a prefix of the profile name in which it's looking (which is how each profile defines it's own value).

Rhapsody uses this mechanism in it's own General::Model::VolatileProperties property. It starts with the following - which is the indicator to Rhapsody to evaulate this property and not just use it as a string 

?<IsConditionalProperty>

Next there are two more parts. The first reads another property:

$<General::Model::DefaultVolatileProperties>,

And the second checks all loaded profiles for a General::Model::VolatileProperties property (except that the VolatileProperties part should be prefixed by the profile name)

$<Profiles::General::Model::VolatileProperties::,>

Example

Another good example is custom model browsers. Rhapsody has a property AdditionalBrowseHierarchy where those additional browsers are defined. But if you have multiple profiles and they all define browsers using that same property - only one profile will win and only it's custom browsers will show up. But if you use the Profiles conditional property then you can get them all.

I use this in my Profile Builder tool - custom browsers are automatically generated as two properties - one for the AdditionalBrowseHierarchy and a second AdditionalBrowseHierarchy with the profile name prefix. That means that any profiles you create using that tool will all be compatible with other profiles.

For example here is a snippet from it's own HEP file (the Profile Builder profile has custom browsers too) - these two properties are under Model::Project since this is part of a custom browser definition at project level:

This first property tells Rhapsody to check all loaded profiles for an AdditionalBrowseHierarchy property 

Property AdditionalBrowseHierarchy String "?<IsConditionalProperty>$<Profiles::Model::Project::AdditionalBrowseHierarchy::,>"

And then this is the profile-specific version of that property that Rhapsody will find

Property ProfileBuilderAdditionalBrowseHierarchy String "CustomBrowser_Browse_Properties,CustomBrowser_Browse_Includes_Properties,CustomBrowser_Browse_Helpers,CustomBrowser_Browse_Add_New_Menus,CustomBrowser_Browse_Context_Patterns"

A quick Rhapsody API tip since this particular function is undocumented:

getOverriddenPropertiesByPattern (String, int, int)

Takes three arguments:

• String pattern
• int localyOverridenOnly - not my spelling mistake that is exactly how it appears in the JavaDoc :)
• int withDefaultValues

Pattern

This string ahould be in the form Subject.Metaclass.Pattern but any 2 of the three may be omitted, for example you can use:

"General.." to get all overridden properties with a subject of General

".Model." to get all overridden properties with a metaclass of Model

You get the idea !

LocalyOverridenOnly

Works as expected - setting this to 0 returns overridden, setting it to 1 returns locally overridden.

With Default Values

Does not work at all how you expect. Setting this to 1 makes the function ignore the pattern entirely and return all overridden properties - with their current value (not their default one).