Shape Scripts not executing in Azure SQL

[MattAtRamsay]

Hello

This is something I reported to Sparx Support on 3/11 and await a response, despite chasing (see insert below for some details).

Essentially, I have a profile with shape scripts. These shape scripts work very well when they are deployed to a local test repository. When deployed to a repository in Azure SQL, they do not execute - the base shape is shown instead. I speculated that the DBMS connection type may have been at issue, but have now confirmed the same thing happens with a PCS Cloud connection. I realise this was clutching at straws since the scripts will execute within EA and within memory on the client, and not touch the server in any way shape or form. However, it is a function of the DBMS deployment - as indicated by the fact it works in a local test repository.

Does anyone have please any pointers on what might be at issue and things I can try? If you can beat support with their 17 day headstart, then there'll be extra kudos! 

All the best - Matt

ENVIRONMENT DETAILS
Enterprise Architect
Edition : Ultimate Floating
Version : 16.1.1625.64bit
Extensions :
Other Addin :
Operation Systems : Windows 10
System Type : 64bit
Connection Type : Server
DBMS: SQLServer
Connection String : Ramsay EA Cloud Repository" --- DBType=1;Connect=Provider=SSDB;SRC=a.b.c.d@sql-db-sparxea;UID=p.q@sql-srv-sparxea;PWD=somethingImadeuptoavoidsharingmypassword;trust=1
-------------------------------------------------------------------------------
ISSUE DETAILS
Summary:
Shape Scripts not executing in Azure SQL repository

Details:
Hello
I am developing a profile with shape scripts, and these shape scripts work very well when they are deployed to a local test repository. When deployed to a repository in Azure SQL, they do not execute - the base shape is shown instead. The shape script is attached.
I wonder if it is significant that we are using a Server connection type even though this is a cloud repository, as we have not deployed PCS. We have not tested the deployed MDG in an Azure SQL repository via a PCS cloud connection and would like to do so, but are unable to stand up that resource currently. Is this something you could test using a Sparx Systems Azure SQL repository - if you have such a test bed?
All the best,
Matt

Steps to Reproduce:
Create a new stereotype of component and add the shape script.
Add an image to the image manager called "CustomImage" (rename as appropriate).
Test the deployed MDG in a local repository.
Test the deployed MDG in an Azure SQL repository (with Server connection).
Ideally, test the deployed MDG in an Azure SQL repository with a PCS connection.

[Geert Bellekens]

Are you deploying your profile using an MDG?

We have a setup using an Azure SQL, and lots of own crafted profile, but never had any issues with the shapescripts.
We deploy our profiles using an MDG imported into the model.

Geert

[MattAtRamsay]

Hi Geert

That's good to know. So Azure SQL is a red herring, then? Good news. I therefore need to narrow down the problem to something else.

The profile is imported using an MDG, and I've tried all approaches to including it in the model - User, Model and System (placing in the system MDG folder). I've also done it by path but that's only good with a shared path which we don't currently have.

I'm using the same client to open the local test repository in EA as I am to open the Azure SQL repository.

I just don't get it. I must be missing something and it is probably obvious.

Thanks

[MattAtRamsay]

Update on the above ...

Recap:

• MDG with shapescripts.
• Shapescripts work in local .eap
• Shapescripts don't work in Azure SQL repo (regardless of connection type)

I thought I'd try something bizarre, not expecting it to work, but it did.
What'd I do, you might ask? I copied the package of new stereotyped elements and diagram from the local repo to the Azure SQL rep using "Full structure for duplication".
Lo, and behold! Yes the diagram displays the elements as per the shape scripts.
But that's not all. If I drag one of those nicely rendered elements onto a newly created diagram (of the same type), then the shape script does not work. The diagram is of the same type.
All other things look right - the toolbar icons, etc.

I wonder what can be concluded from this?

[Geert Bellekens]

There's an option somewhere on a diagram to disable rendering shapescripts.
Diagram Properties | Elements | Show Shapescripts

Maybe that's the issue?

Geert

[MattAtRamsay]

Hi Geert

You are correct - there is a setting that seems like the most plausible explanation, but it is not that causing the problem. Hard to believe, I know, but both the pasted diagram that does show the shapes, and the ones created anew in the model have this setting enabled.

I've also dragged elements that were created on a diagram that doesn't show shape scripts onto a diagram that does, and the shape scripts show. Vice versa: I've dragged elements from the diagram that shows the shape scripts onto one that doesn't, and the copied element shows the native shape.

This is bizarre. I'll check that the data schema update script was run on the database ... clutching at straws now.

All the best,

Matt

[MattAtRamsay]

Update - nothing to do with the underlying SQL schema - I checked and the 1558 update script was run successfully when the repository was set up.

I have found the problem though! 

There is a property that you can't see (I haven't seen, anyway) on the properties dialogue window. However it is visible in the properties browser. It is in the diagram appearance section, and is the check box for "Custom Style". If ticked, it prevents Shape Scripts from running.

I have been thinking why it was set to Custom Style for the diagram in one case but not another. I checked the profile, and there's no way (I can see) to set the property for the new diagram type. I would have remembered doing so, anyway. By creating a new diagram using my toolbar, shape scripts do work on that diagram. I think it happened to a diagram I created in the model when I unloaded the MDG from the model, in order to bring in an updated version of the MDG. Hypothesis - when an MDG created diagram is divorced from its MDG, it gets the Custom Style check box checked? Maybe.