Page History
Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Div | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
|
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)
Image Modified
Image Modified
The concerned elements are marked with a red cross (Image Modified) in the containment tree. Parent elements of concerned elements are marked with a gray cross.
Image Modified
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
Image Modified
Right-click on an erroneous element and select Use Another Element... to replace the recovered element by the correct type.
Figure: Replace Recovered Element
Image Modified
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.
Anchor | ||||
---|---|---|---|---|
|
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
Image Modified
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.
Anchor | ||||
---|---|---|---|---|
|
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 Block |
---|
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(); |
|
|
set myVar.key='myOtherKey'; |
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
Multiexcerpt include | ||||
---|---|---|---|---|
|
Solution
Multiexcerpt include | ||||
---|---|---|---|---|
|
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).
Panel | ||
---|---|---|
| ||
|
Panel | ||
---|---|---|
| ||
|