Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Roman Liebsch

Pages: [1]
1
Hi netizensmith,

I can confirm that bug.

Your point and use case is a valid use case where you have to cope with multiple MDGs at the same time. We also have such use cases.
Let me say a generic modelling MDG with common elements for systems and software development, and a special MDG with extended elements for special software use case only. Both will be deployed separately and the latter one can be hidden with perspectives or so.
With the separation of concerns we ease the maintenance of those toolboxes.

The main benefit for me is to have more common elements always pinned like "Text" or "Boundary".  No one would prefer to change the toolbox to get a "Boundary" I think.

Regards
Roman

2
I found a workaround.

If I use the VEA folder from EA 16.1.1628 in the EA17.0.1703 folder then symbols arise again.

BUG is reported to EA now.

3
In 17 I am not able to debug java scripts and evaluate for instance COM objects like a Msxml2 DOMDocument in the "Locals". They are not shown at all. And if I try a mouse-over on such variables the debugger even stops execution.

In EA 16 it is working perfectly fine.
I might remember in former EA version where you have to install the old Microsoft Script Debugger but I guess Sparxs completely swtiched to JavaScript.

Anyone the same issue or even a solution?

Thanks!
Roman

4
Bugs and Issues / Re: Native XML import hangs
« on: March 24, 2021, 11:54:57 pm »
Hi Geert,

I faced those issues very often using the cloud connection either with XMI 1.1, Asset Service (=XMI) or Native. I have already reported it to Sparx end of 2019.
Shortly, for those big imports where a lot of references are missing in the new repos, using cloud connection will fail on our side with a timeout.
However in the intranet (not via VPN) it is working most of the times with a direct ODBC mySQL connection. Native is working only with ODBC mySQL and EA1558 - I used it last week that way quite successfully.
For me it is a bug introduced in EA14 handling unresolvable relationships together with the cloud connection backend, so I use ODBC only for that.

Here my bug description, maybe it helps you investigating:

Summary:
EA crashes with data loss on bigger transaction (XMI Import, Baseline...)
Details:
If I want to exchange bigger data among different repositories than I use first an XMI export with Version 1.1(in EA15 I also tried "Native") that is working so far.
But the import is crashing or hanging when using larger files and often when there are a lot of references not solvable as I update a sub package of a larger context.
So I will have an inconsistent project afterwards.
I often get an WAIT_TIMEOUT from the Cloud Service, based on a OBDC Warning of a found Deadlock.
"Pro Cloud Server: Query in batch execute failed with message: FAIL: Microsoft OLE DB Provider for ODBC Drivers [-2147467259] [MySQL][ODBC 8.0(w) Driver][mysqld-8.0.19]Deadlock found when trying to get lock; try restarting transaction"
Either EA will hang (and GUI will soften in the background) at the import stage "Resolving Link" or "Fix Up external References" for example, the adding stage is often not critical.
Or I will get the message OLED Persistence Provider : ....not enough Memory for the transaction that ends in an "Out of Memory" error of EA. Then EA will not react anymore.
I guess it is even worse if I keep on working with other programs and the focus to the EA GUI is lost.
I is a little bit more stable using a direct OBDC connection from the client instead of the Cloud connection but it crashes likewise.

However if I use the EA1354 the deadlock warning still appears from time to time but EA13 will keep on importing and fixing all references and so right without and Out of Memory error.

Sparx Support answer:
When you were importing the XML file(s) and receiving the deadlock error, did the folder containing the information being imported already exist in the repository?  The only time we were able to duplicate that error is when EA had to delete the previous information before doing the import, this occurs for all XMI 1.1 imports.  We will need to investigate the cause of these deadlocks.

One of your comments mentioned Native imports.  Can you round trip Native XML export/imports without errors?  We ask because the Native XML import does not delete previous information before importing, it simple updates any data already present.  The Native XML export/import has been designed from the ground up to be as fast as possible by reducing the amount of data being transferred over the network which greatly improves performance.

Can you described your environment in particular the location of the Pro Cloud and Database servers?  The communications between EA and the Pro Cloud Server have been optimized however the Pro Cloud Server requires/assumes it has near immediate access to the database server, and will open 100's (if not 1000's) of database queries, therefore if the PCS is located in one network and the database server in another general performance will be impacted and in the worst cases, timeouts will occur.


Regards
Roman

5
I found out another solutions (currently EA 15.2.1557) which leads to same definition as with drag and drop mentioned before.

Instead of using the Property->Type in tab Properties
you can select the Part->Type in tab Element

then the filter is open for standard Property types again  ;) :
Quote
Types : 'Port','Activity','Class','DataType','Interaction'...
Stereotypes : ...

If you want to restrict the filter for Part->Type regarding your MDG stereotypes, you need to redefine SysML1.4::FlowProperty with FlowProperty and add metaconstraints (umlRole=classifier) to your own stereotypes. [ref. to EA MDG Help chapter "Redefine Stereotypes in Another Profile","Define Metamodel Constraints"]

Maybe with future SysML the change the definition again and as long as SPARX keep the existing workarounds, I am fine with that.

6
Hi Guillaume,

I know it is quite old but the behavior is back in EA 15.2.

We also use our own stereotypes "Flow" in our MBSE toolbox to highlight the semantic and it we were able to choose with EA13.5 'til 15.1 any classifier type.
EA filter was
Types : Classifiers such as Classes, Actors, Activities etc.

Now SPARX changed the filter to
Types : 'Class','DataType','Signal'
Stereotypes : SysML1.4::block,SysML1.4::ValueType


Now we are not able to select our own stereotypes which are even a generalization of SysML1.4::Block.

The workaround for us is to use drag and drop from the project browser on the block and select

Drop as: SysML1.4::FlowProperty (Part)

However to my mind Sparx interpreted the SysML1.5
Quote
Constraints
[1]A FlowProperty shall be typed by a ValueType, Block, or Signal.
too strictly as the stereotype Block is in fact an extension of UML4SysML::Class and FlowProperty is an extension of UML4SysML::Property which binds classifies.

That would avoid to use own toolboxes for SysML, and I doubt that shall be the intention of SysML1.5!

Roman

7
The template feature is a nice feature to prepare project specific templates for special elements but it could be improved.

Okay obviously it is intended to be used for "Display Options" acc. to SPARX:
Quote
When you are creating a new element, the system checks for that element type in the Templates Package and, if it finds that element type, will copy the template element as defined. The definition includes any default display options of the template element,...


but it is really coping the whole content like attribute, notes, tags and their "default" content, even for <memo> etc. of our own stereotypes of our toolbox.
That is what the users like to use as I cannot setup some of them via the toolbox.

So far so good, now let's come to my use cases:
  • UC1: If I drag the stereotype from the toolbox on a diagram, everything is working fine and I get a real copy.
  • UC2: Doing via Add Element... EA does not copy the content, I think as the trigger is different and not started from a diagram. I would appreciate to act as UC1.
  • UC3: Now it comes really strange, if I drag a stereotype (extension of metaclass Requirement) from the toolbox on a package, then EA creates for that stereotype 2 stereotypes - the chosen one and another of same metaclass and even copies the content of the other one. And that is really not a feature and makes us trouble. It seems that is only the case if I use the metaclass Requirement; for Class EA acts like UC2.

Can someone confirm or has an idea what I am doing wrong?

Roman

8
It is an old issues which I have also requested to Sparx. Just want to leave my experience here.
 
My Background is similar and reproducible for XMI and RAS.

If I want to exchange bigger data among different repositories than I use first an XMI export with Version 1.1(in EA15 I also tried "Native") or RAS register - that is working so far.
But the import is crashing or hanging via XMI or RAS when using larger files and often when there are a lot of references not solvable as I use a sub package of a larger context.
So I will have an inconsistent project afterwards.
I often get an WAIT_TIMEOUT from the Cloud Service, based on a OBDC Warning of a found Deadlock.
Either EA will hang (and GUI will soften in the background) at the import stage "Resolving Link" or "Fix Up external References" for example, the adding stage is often not critical. At the end EA hangs and does not consume any memory anymore if I look to the Task manager.

Big imports using ODBC on the server itself only work with the ODBC and even there the cloud connection fails. So the LAN/WAN in between shouldn't be an issue.

However if I use the EA1354 the deadlock warning still appears from time to time but EA13 will keep on importing and fixing all references right without an Out of Memory error. But I don't want to use EA13 anymore.

Even playing around with different versions of MySql and the ODBC Connectors won't solve the issue. I believe that there is kind of time out or buggy failure reaction in the cloud service on a lot of missing references that are not found in the repos.

Sparx answered:
Quote
When you were importing the XML file(s) and receiving the deadlock error, did the folder containing the information being imported already exist in the repository?  The only time we were able to duplicate that error is when EA had to delete the previous information before doing the import, this occurs for all XMI 1.1 imports.  We will need to investigate the cause of these deadlocks.

Pages: [1]