Troubleshooting the Builder

Problems Migrating Projects from MagicDraw 17 to 18

Please refer to Troubleshooting MagicDraw 18 for any migration related problems.

MagicDraw 18 Model Contains Recovered Elements

Problem

When opening the model, MagicDraw shows a notification message and error messages in the bottom right corner in the status bar.

Figure: Message Recovered Elements (MagicDraw 18)

The concerned elements are marked with a red cross (

) in the containment tree. Parent elements of concerned elements are marked with a gray cross.

The model will not compile after saving it.

Example

This problem occurs, if imported types have changed. MagicDraw does not find the type definition anymore and creates a recovered element as a replacement.

Solution

Click on the envelope in the MagicDraw status bar. MagicDraw will show you a detailed list with all validation results.

Figure: Validation Results

Right-click on an erroneous element and select Use Another Element... to replace the recovered element by the correct type.

Figure: Replace Recovered Element

MagicDraw shows the containment tree with the recovered element selected. Select the correct element and click OK. MagicDraw will delete the recovered element and remove the corresponding line of the validation result list.
Repeat this for all lines of the validation results.

Model Contains Orphaned Proxies

Problem

When opening the service model, a MagicDraw messaging window pops up showing the warning:

Orphaned proxies found in module [...]. To resolve them, read the resolution instructions. Orphaned proxies are listed in the Active Validation results and can also be displayed using the Search function, with the "Orphaned proxies only" option selected.

Having orphaned proxies means, that the model references elements (e.g. class attributes, parameters, ...) that are no longer available. This is a normal situation in software development, where a piece of software may undergo changes, e.g. when re-importing an external resource (xsd) where some types have been renamed or moved. If these types have been referenced in a mapping dependency, MagicDraw alerts orphaned proxies that have to be resolved.

Example

This problem often occurs e.g. when a BPMN or an XSD is re-imported after a change. The orphaned proxies then reflect the state before the re-import.

Solution

Click the second link of the message ([...] the Search function, with the "Orphaned proxies only" option selected). MagicDraw will perform a search for orphaned proxies and display the result in the Search Results tab.

Figure: List of Orphaned Proxies in the Search Results Tab

To resolve these orphaned proxies, right-click an orphaned proxy and selectOrphaned Proxy Resolution from the context menu. You have got two possible ways to resolve orphaned proxies:

clear all proxy usages
All occurrences of the missing referenced element are removed from the model.
replace all proxy usages
Select an element to replace all proxy usages with. If you try to replace complex structures, you will have to replace the inner elements first (e.g. attributes) and then the wrapping elements (e.g. classes).

Using Find Proxy Usages, you can search your model for proxy usages.
Having more than one orphaned proxy, you can use multi-select to work on all proxy usages at a time.

Orphaned Proxies are sticking

Problem

The service model contains orphaned proxies and they have been removed as described above. After saving and reopening the model, the orphaned proxies are back.

Solution

The sticking orphaned proxies may be coming from an imported module. Open all import files and check all them for orphaned proxies. If you find orphaned proxies in such a module, remove them as described above.

Compiler Reports Error: Local variable is re-declared

Problem

On compiling a model, the Compiler reports: Local variable 'myVar' declared on line 2 is re-declared on line 3.

Solution

Assume, you have an Action Script like this:

CODE

local myVar = '';
local myVar = myObject.stringAttribute if myObject.stringAttribute.exists();

Local varable myVar is a String variable that is declared twice in the Action Script. It is initialized with "empty string". In a second step, this initial value is overwritten by a string attribute, if existing.

Compiler behavior in BUILDER versions before 6.0.28 / 7.0.0	`myVar` contains an empty string. The initial value of `myValue` is preserved, if the condition of the second statement evaluates to false.
Compiler behavior in BUILDER versions as of 6.0.28 / 7.0.0	`myVar` is `NULL`. If the condition of the second statement evaluates to false, contents of `myVar` are set to `NULL`.

Reason for this is that we now transform local a = b if c; to local a = condition(c, b, null);. The old behavior caused problems with wrong variable initialization in iterations.

Re-declaring a local variable is no good practice. As of Builder 6.0.29 / 7.2.0, the Compiler reports an error in this case.
In case the Compiler points you to a implementation like this, you should replace the second (or more) [create] local statements by a set statement.

Code Examples

Old Implementation Improved Implementation

local myVar = '';
local myVar = myObject.stringAttribute if myObject.stringAttribute.exists();

local myVar = '';
set myVar = myObject.stringAttribute if myObject.stringAttribute.exists();

create local myVar using myComplexTypeReference; set myVar.key='myFirstKey'; set myVar.value='myFirstValue'; append myVar to someArray;

create local myVar using myComplexTypeReference;
set myVar.key='myOtherKey';
set myVar.value='myOtherValue';
append myVar to someArray;

create local myVar1 using myComplexTypeReference; set myVar1.key='myFirstKey'; set myVar1.value='myFirstValue'; append myVar1 to someArray;

create local myVar2 using myComplexTypeReference;
set myVar2.key='myOtherKey';
set myVar2.value='myOtherValue';
append myVar2 to someArray;

create local myVar using myComplexTypeReference;

set myVar.key='myFirstKey'; set myVar.value='myFirstValue'; append myVar.copy() to someArray;

set myVar.key='myOtherKey';
set myVar.value='myOtherValue';
append myVar.copy() to someArray;

Cannot Start Service in Embedded xUML Runtime

Problem

The service cannot be started due to one of the following errors:

Fatal:Internal:BELM:11:Configuration for function create...f1170514100h-1882201659.0_1 not found
Fatal:Internal:BELM:25:Source function "create...f1170514100h-1882201659.0_1" of mapper "sm1170514100h-937846676"[0] not found.
Fatal:Internal:BELM:23:Initializing component "urn:Services.UITable.createSupportCase" failed.
Fatal:Internal:SRVLM:8:Startup failed.
Fatal:External:XMLLM:6:Could not open repository file "xxxx\examples\Add-ons\JMS\.$bin\simpleStatSendReceive_Deployment_GlassFish_FileJNDI.GlassFishFile_simpleStatSendReceiveExample.GlassFishFile_simpleStatSendReceiveExample\repository\tabfiles/AddOns/SOAP/Support/dataItem.tab" for reading.

Solution

The overall path to the repository is too long. Shorten the name of the model and/or the name of the composite to avoid this limitation.

Cannot Deploy Service to Bridge

Problem

Bridge 7 When deploying an xUML service, the following error is displayed:

For input string: "${global_e2e_configuration_controller_Port}".short(Errorcode:For input string: "${global_e2e_configuration_controller_Port}")

Solution

You tried to deploy a service compiled with Builder 7.0.0-beta3 to a Bridge with a version older than 7.0.0-beta3. As of the mentioned version, the Builder features variable port numbers. Builder version and Bridge version must match in this case.

Update your Bridge to the necessary version, 7.0.0-beta3 or higher.
Downgrade your Builder to a version older than 7.0.0-beta3.

Cannot Deploy Service to Bridge (MagicDraw 17)

Problem

The service cannot be deployed from MagicDraw 17 to an Bridge due to a Tomcat handshake error.

Solution

You have disabled TLS 1.0 for Tomcat on the target Bridge (see Bridge Hardening).

MagicDraw 17 uses Java 6, and thus only supports protocols up to TLS 1.0. So, if you have disabled Tomcat TLS 1.0 on your Bridge, you will not be able to deploy services directly from MagicDraw 17 to this Bridge.
Nevertheless, you can still compile the service to a service repository and upload this repository manually via the Bridge UI (see Deployment of xUML Services).

Cannot Access External Database via Embedded xUML Runtime

Problem

A service running on the xUML Runtime that is embedded to the Builder cannot access an external database backend.

Solution

If you want to access an external database backend via the embedded xUML Runtime, you have to install a database client and make it available to the Builder by adding its location to the system PATH (see also Installing and Configuring Database Access).
In the Run window of the embedded Runtime, you can configure the database preferences of the service in tab Preferences > Add-on Settings (see Changing the Service Preferences).

Related Pages:

Troubleshooting MagicDraw 18