Issues with the upgrade to PCS 5.1.128

[Modesto Vega]

Before Christmas we completed an upgrade to PCS 5.1.128 (and WebEA v5.1.128.2650) and found some issues for which we have an open support case. Considering the initial reply to the support case, I thought it could be good to post in the forum and see if anybody has seeing something similar. The issues are:

1) WebEA has stopped working when connecting to models with Model Security enabled. Prior to the update, WebEA worked fine with the same configuration.

2) The PCS log is littered with messages like "[WARNING]: [Active Directory] Failed to set name to translate 2023-12-21 17:09:37 [WARNING]: Name translation: Unable to resolve completely, only the domain was found." followed by "[WARNING]: Thread 60 Authentication - Windows: user '[DOMAIN]\[USERNAME]' is not valid for model 'Sparx_EA_Repository'". However, all models are accessible through Sparx EA via PCS, and none of the users are getting any error messages.

3) We have also noticed that PCS Config reports Pro Models 0 / 7 but cannot recall if we were seeing something similar with the previous version.

The 2nd issue is odd, model security still works despite the warning, PCS appears to be using the e-mail address instead of the fully qualified username - i.e., [USERNAME]@[DOMAIN] instead of [DOMAIN]\[USERNAME], it fails when when it tries to use [DOMAIN]\[USERNAME] but succeeds when it tries [USERNAME]@[DOMAIN].

[Modesto Vega]

The answer to issues 1 and 3 was obvious, I just wish Sparx Systems support tried to at least understand/read the change requests and OCS/WebEA had better error messages.

When we carried out the upgrade, we found that none of the database connections were working and, since it is not possible to edit the connection strings we had to recreate them all and, of course, when creating a model connection the "Enable Pro Features (OSLC, WebEA and Integration)" setting is disabled by default.

The 2nd issue is still a mystery to us.

One other point regarding database connections, the new "Native Connections" force PCS administrators to specify a username and password, instead of using the username, in our case Active Directory service account, running the PCS windows service. This is rather unfortunate and, in my opinion, unecessary.

[shimon]

Hi,
I have been asked by the DBA to use an Active Directory account in the connection string. Is this possible when not using PCS?
As we will be forced to use Pro Cloud Server, I am wondering if this is a known issue, that using PCS you cannot define a AD account?
Thanks,
Shimon

[Modesto Vega]

It is possible to use an AD account to connect Sparx EA to the database without using PCS. The only requirement is for the AD account to have the right database permissions.

[mariahcarey]

Before Christmas we completed an upgrade to PCS 5.1.128 (and WebEA v5.1.128.2650) and found some issues for which we have an open support case. Considering the initial reply to the support case, I thought it could be good to post in the forum and see if anybody has seeing something similar. The issues are:

1) WebEA has stopped working when connecting to models with Model Security enabled. Prior to the update, WebEA worked fine with the same configuration.

2) The PCS log is littered with messages like "[WARNING]: [Active Directory] Failed to set name to translate 2023-12-21 17:09:37 [WARNING]: Name translation: Unable to resolve completely, only the domain was found." followed by "[WARNING]: Thread 60 Authentication - Windows: user '[DOMAIN]\[USERNAME]' is not valid for model 'Sparx_EA_Repository'". However, all models are accessible through Sparx EA via PCS, and none of the users are getting any error messages.wordle

3) We have also noticed that PCS Config reports Pro Models 0 / 7 but cannot recall if we were seeing something similar with the previous version.

The 2nd issue is odd, model security still works despite the warning, PCS appears to be using the e-mail address instead of the fully qualified username - i.e., [USERNAME]@[DOMAIN] instead of [DOMAIN]\[USERNAME], it fails when when it tries to use [DOMAIN]\[USERNAME] but succeeds when it tries [USERNAME]@[DOMAIN].

I just tried it out of fun. And I had no issue.