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 - blaisephilip

Pages: [1] 2
Thanks for the hints about t_document content! I've implemented the solution by assembling the date of creation and the rest to a single XML output.
The GUID of the baseline (available as attribute in a baseline node within the raw XML) is actually the t_document table's DocID column.

Code: [Select]
        private void GetPackageBaselineInfo(Package pkg)
            if (cfgHandling.bBaselineInfoSupport)
                log("Available package baselines are collected for release history...");

                Project projInterface = currentRepository.GetProjectInterface();
                XmlDocument baselineInfo = new XmlDocument();
                // this retrieves only GUID, version, name and notes for the baseline
                string sBaselineInfoRaw = projInterface.GetBaselines(pkg.PackageGUID, "");
                sBaselineInfoRaw = sBaselineInfoRaw.Replace("><Baseline ", ">\r\n<Baseline ");
                XmlNode blCollection = baselineInfo.SelectSingleNode("EA.BaseLines");

                if ((baselineInfo != null) && (blCollection != null))
                    XmlDocument baselineInfoExt = (XmlDocument)baselineInfo.Clone(); // extended baseline info, to be exported
                    XmlAttribute cDate = baselineInfoExt.CreateAttribute("creationdate");
                    if (cDate == null)
                        log("Creation date could not be added as new attribute. No baseline info will be extracted.");
                    if (baselineInfoExt == null)
                        log("Output baseline info XML creation failed.");
                        log("Count of available baselines: " + blCollection.ChildNodes.Count.ToString());
                        // take each baseline to get the date of creation too
                        foreach (XmlNode node in blCollection.ChildNodes)
                            string guid = GetAttributeValue(node, "guid");
                            if (guid != null)
                                string sQuery = "SELECT `DocDate` FROM `t_document` WHERE `DocID` LIKE \"" + guid + "\"";
                                string date = currentRepository.SQLQuery(sQuery); // date is still raw XML, as date+time
                                XmlDocument DateXML = new XmlDocument();
                                DateTime dtDate = DateTime.Parse(DateXML.SelectSingleNode("//DocDate").InnerText);
                                // insert the date of creation to the baseline XML
                                XmlNode targetNode = baselineInfoExt.SelectSingleNode("//Baseline[@guid='" + guid + "']");
                                if (targetNode != null)
                                    cDate.Value = dtDate.Date.ToString("yyyy-MM-dd");
                                    log("Target node not found by baseline GUID.");
                                log("Package baseline with empty GUID found. This shall be an error. The process ends now.");
                        log("Baseline content collected, writing to XML...");
                        baselineInfoExt.Save(Path.Combine(cfgHandling.sAddInPath, "temp_baselines.xml"));
                        log("Baseline information saved to XML.");
                    log("Node collection not found.");

I'm developing an add-in and need to access the creation dates of a package's baselines and use these as part of a generated document's release history.
The following snippet retrieves the baseline information's basic elements (version, name, notes) correctly as raw XML.

Code: [Select]
Project projInterface = currentRepository.GetProjectInterface();
        string baselineInfo = projInterface.GetBaselines(pkg.PackageGUID, "");

So, baselineInfo can be post-processed to become part of the document. However, it does not contain any information about the baseline's creation date. In our case, I could ask users to use a manually entered date entry in the baseline notes but that could be falsified, so I don't want to go with that option.
The EA Menu's Design --> Package -> Manage -> Find Baselines feature provides a Baseline_Date column for all baselines of a package, with help of the Find in Project feature. So in the DB there is at least a table that stores the baseline creation date values.

Is there any way to reach the Baseline_Date values with help of the object model in a C# add-in?

Hi Geert

Just as an update:
I got it working with the Setup Project template of Visual Studio.

COM-Visibility option for the main library: vsdrpCOMRelativePath
Important was the proper setting of registry keys via VBScript in the Custom Actions of the Setup Project:

Custom action for Commit:
Code: [Select]
Set WshShell = CreateObject("WScript.Shell")
WshShell.RegWrite "HKEY_CURRENT_USER\SOFTWARE\Sparx Systems\EAAddins64\specialnewtoolbox\", "specialnewtoolbox.mainclassname", "REG_SZ"
Set WshShell = Nothing

Custom action for Uninstall:
Code: [Select]
Set WshShell = CreateObject("WScript.Shell")
addinKey = "HKEY_CURRENT_USER\SOFTWARE\Sparx Systems\EAAddins64\specialnewtoolbox\"
WshShell.RegDelete addinKey
Set WshShell = Nothing

Both actions shall have the option Run64Bit on True, for 64-bit installer.

Same changes from a C# executable failed to handle the proper registry keys, it created (Default) duplicates. Similar problem was also addressed in this article:

The original issue is now resolved.

Thanks for the hints, Geert.
After spending the day recreating templates and stylesheets, I decided that only a document post-processor independent from EA will do this right.
There is absolutely zero effect on the headers and footers in my case in the output documents, not even by using the built-in templates, if I use the EA.DocumentGenerator.
The manual process works good but that is not suitable for my needs if I need to repetitively generate lots of instances.

I'm using a self-developed document generator add-in in EA V16.1.1628 to create .docx files as output. The following code is the main part of exporting the EA content:

Code: [Select]
      Package package = currentRepository.GetTreeSelectedPackage();
      DocumentGenerator docGen = currentRepository.CreateDocumentGenerator();
      // call the iterative content generation
      contentGenerator(docGen, cfgHandling.logwindowName, currentRepository, package, 0, cfgHandling.reqSpecSecTemplateName);

      string filepath = Environment.GetFolderPath(Environment.SpecialFolder.Desktop) + cfgHandling.mainSavePath + "\\" + cfgHandling.project_id + "_Req_Spec." + cfgHandling.mainDocExt;
      docGen.SaveDocument(filepath, cfgHandling.mainDocType);

cfgHandling.reqSpecSecTemplateName refers to the name of the template in the repository that contains the desired formatting.  (note: I use a MySQL database behind Pro Cloud Server)

The following is the header I use in the document's template:

This is completely ignored in the output document. I get blank header and footer, so the result breaks the rules of corporate guidelines, and renders the output in this form not usable.
Could anyone suggest which part of the code or EA overrides the template's header formatting?
(As backup plan, I'm considering writing a post-processor with Microsoft.Office.Interop.Word if fixing the Sparx EA document build fails.)

I'm developing a document generator add-in with installer package to distribute it over our organization. So far I came to the following results:

1. There is no chance to get this done via WiX due to heat.exe's poor support for 64-bit libraries currently.

2. The Setup Project template of Visual Studio 2022 V17.9.4 fails to add registry entries properly. EA, from whatever unfortunate reason, expects the first (Default) key value to be filled with the library's main namespace value and class name. (namespace_name.class_name format) The Setup Project installer adds the first value as empty, and creates a second (Default) with the proper value. So, totally unusable for EA during startup. Automated custom actions (usable in Setup Project template of VS) during install fail to fix this due to the nature of the (Default) key.
Still, after manual fix, the add-in loads, operations are performing as expected, but... it cannot load a logging subwindow to EA that I use for feedback towards users.

When the library is registered via regasm for debugging, the subwindow interaction is correct. So I think the registering of the library is the issue to COM.
Possible options for library registering in the Setup Project for the library, and results:
a) vsdrpCOMSelfReg  --> Build error: The assembly 'xyz.dll' in project output group 'Primary output from MainNamespaceName(Release x64)' cannot be self-registered.
b) vsdrpCOM or vsdrpCOMRelativePath --> The add-in is installed, I correct the false registry entries manually, operations work - but the log window still not shows up..
I cannot roll out an add-in without any feedback on the UI about what is happening and how far a triggered process is done in the end-user's EA instance.

So, this is a pretty messy system integration possibility for 64-bit EA currently. Does anyone knows a patch or workaround for this issue? Thanks in advance.

The issue was present with
•   Host environment: Ubuntu 18.04.06 LTS
•   Confluence Server 7.13.7
•   Prolaborate Macro Version: V3.0

Upgrade to Prolaborate Macro Version V3.1 and the issue with General Exception is resolved, disregarding of a diagram's object count.

General Board / Re: EA15.1 - Cannot transfer project from file to MySQL
« on: August 26, 2022, 06:17:47 am »
I've found a solution without using the root user.
I'm using XAMPP & phpMyAdmin to handle MySQL DBs.
Even with granted admin rights for a user, the project transfer will fail - late versions of EA V15 and also V16 has this issue, when transfering from .QEA to DBM. (EAPX->QEA as intermediate transfer is definitely recommended, I've had issues with transfer attempts without .QEA as source format in the past)
So, the patch:
1. Go to phpMyAdmin on the server http://localhost/phpmyadmin/index.php?route=/
2. Select the created empty DB (after applying the current schema (EASchema_1558_MySQL.sql) and initializing the tables (EABase_1558_MySQL.sql))
3. Select User Rights
4. Select the User you intend to use with user/pass in the transfer (QEA->DBM) session
The "Change Rights" site has 4 tabs: Global, Database, Change Password, Login
Choose Database.
5. On this tab, you find a dropdown list where additional rights can be given for this user. (although one would assume that it is sufficient that is already configured, but its not...)
From the dropdown list, select the prepared empty database. It will add a row in the Database-specific rights section in this tab.
"ALL PRIVILEGES" are needed for this entry.
6. At this point, you shall switch to EA and attempt the project transfer with the user account. It shall succeed.
7. If you check again the user permissions in phpMyAdmin, the specific user received a Database-specific placeholder in the user overview. This can be removed after the successful model transfer, it was only necessary to unblock the transfer mechanism. (All other operations worked for me after removing the placeholder.)

PCS Bugs and Issues / [Prolaborate V4.1.2] - User tagging in discussions
« on: August 01, 2022, 08:57:19 pm »
Dear all,
Active Directory-based access for dozens of users is active in our on-premise Prolaborate installation. The authorization is managed via AD group memberships to the roles of Admin, Editor and Reviewer, coupled to identical user groups in Prolaborate. Model security features are enabled.
All users can log in without issues - however, for all Active Directory users the displayed name is as "Surname, First Name" in the Prolaborate Repository Configuration / Users / Edit User / First Name field, and the Last Name field is displayed as empty. The name entries are correct in AD and also displayed correctly if I check the group members in Enterprise Architect.
The main issue is that some users can be tagged in messages while some users cannot in Prolaborate's model-based discussions. The issue affects only some AD Group Users from the tested user roles:
  • Prolaborate Admin
  • Active Directory Group User
  • Identity Provider User
  • Registered User

Does somebody know the background of this issue?

Used version: Prolaborate V4.1.2

In the case of some corporate backgrounds in Prolaborate theme config (Portal Settings --> Theme Settings), the placement of Sign Up, Forgot password etc. is problematic since it is almost not readable due to the background. The opacity of the sign in shield area should be configurable to avoid this. A base color selection is recommended. (valid only for this area)

PCS Bugs and Issues / Re: Restricted package visibility with WebEA
« on: July 14, 2022, 06:26:17 pm »
Thank you, I hoped that we can keep using MySQL, but the row-level security is not supported there, so it would cause a DB transfer for each repository.
I think the only proper way to handle our use case (without additional DB-support-setup on the server) is to migrate the packages with higher confidentiality to another repository without WebEA-activation, but with connection to Prolaborate.

Used version: Sparx Prolaborate
I'm working on Prolaborate - Confluence integration with a certain test space in Confluence.

Some diagrams can be successfully integrated to Conf. pages via the provided macro, some not. In diagrams with a large number of elements the following exception is thrown:

The access to Prolaborate service is not stable. In some phases the server gives the following feedback:

(Prolaborate is working just fine in the other browser window.)

Are there any configurable timeouts that could be set from Confluence-side to avoid these?

Confluence log caused by Prolaborate plugin (in this state, even Confluence login was rendered impossible for some users by the caused load..):

Code: [Select]
25-Jul-2022 13:46:41.318 WARNING [Catalina-utility-2] org.apache.catalina.valves.StuckThreadDetectionValve.notifyStuckThreadDetected Thread [http-nio-80-exec-95 url: /rest/prolaborate-admin/1.0/ProlabConnect; user: <USERXYZ>] (id=[68845]) has been active for [64,826] milliseconds (since [7/25/22 1:45 PM]) to serve the same request for [] and may be stuck (configured threshold for this StuckThreadDetectionValve is [60] seconds). There is/are [1] thread(s) in total that are monitored by this Valve and may be stuck.
at [email protected]/ Method)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/$ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at [email protected]/ Source)
at com.prolaborate.configureui.ConfigResource.GetProlaborateToken(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(
at com.prolaborate.configureui.ConfigResource.GetAPI(

PCS Bugs and Issues / Restricted package visibility with WebEA
« on: July 13, 2022, 11:20:20 pm »
Currently our organization is working with the following setup:
Sparx EA V16.0.1604
Sparx Pro Cloud Server v5.0 (Build 104)
Sparx Prolaborate[/li][/list]

Package visibility is used successfully to restrict user access to some project packages via sections in Prolaborate and via AD Group-based visibility configuration in EA.

However, in WebEA even a user with restricted access towards selected packages can see everything in the model repository. We would not like to turn WebEA off since it helps some scenarios, but it would also be in our interest to hide the packages in question in all 3 systems. (EA-based model editing scenarios, WebEA, Prolaborate)

Is this possible?

Our organization is using the Notes section of different objects to reference repositories e.g. in Github via inserted hyperlinks.
These notes are displayed in Prolaborate after clicking the object in the right pane.
Used from EA and WebEA directly, the user can navigate to the target site via Ctrl+click successfully.
However, the link is not working in Prolaborate. The link is processed with the "unsafe:$inet:" prefix before https:// ... there.
The link itself reacts on left mousebutton click, but due to the prefix no browser can display the site in the new tab.
Is there a solution for this?

Thank you for the solution, it worked. I can proceed with repository configurations now.

Pages: [1] 2