Anybody using Pro Clolud Server to integrate multiple EA repositories?

[Paolo F Cantoni]

From Integrate Data from External Providers;
The Pro Cloud Server helps you to integrate the data from external providers into an Enterprise Architect model. Enterprise Architect is a team player and through its powerful server-based integration capability allows models to be created relating elements from a wide range of disparate tools that contain items from strategy and requirements down to implementation, work packages and configuration items. Enterprise Architect does not manage the master-record for these items but rather acts as an accumulator, bringing content into a single repository and allowing the items to be related.

While the ability to link to disparate external providers (such as Jira) is enticing, our interest is, for the present, limited to being able to "integrate" a number of EA repositories.
Has anyone seriously investigated this? Are you willing you share your experiences and views?

We are coming to the conclusion that while, conceptually, we can define a single corporate repository, in practice we are likely to end up with a number of related repositories sharing certain vertices, arcs and viewpoints.  We have been using package transport to date, but this doesn't really scale.

This seems like a potential solution, but it's not clear if it would meet our requirements (still to be formalised).

We're looking of input to help us work out what is the best architectural solution for our needs.

TIA,
Paolo

[Edit: if there is no response (because nobody has actually tried the new Sparx Adware), I'd like to investigate what would be necessary to define such a mechanism.]

[Edit2:  I just noticed on Install and Configure;
EA plug-in    The EASbpi.exe plug-in interacts with external Sparx Systems's Enterprise Architect Cloud-based repositories.

Does that mean it CAN'T be used with local repositories?]

[Geert Bellekens]

I don't know, haven't tried it yet.

What we do is use version controlled packages (TFS in Azure Devops) to share parts of our "enterprise" model with the "project" models.
It's a one-way integration for us. Enterprise model elements are only ever edited in the enterprise model, in the project models they are read-only.
Seems to be working just fine if you can uphold this strategy.

Geert

[Paolo F Cantoni]

I don't know, haven't tried it yet.

What we do is use version controlled packages (TFS in Azure DevOps) to share parts of our "enterprise" model with the "project" models.
It's a one-way integration for us. Enterprise model elements are only ever edited in the enterprise model, in the project models they are read-only.
Seems to be working just fine if you can uphold this strategy.

Geert

So did we, but we're finding we really need 2-way integration.  Also, the granularity of our packages is too large, we are building a "digital twin".

As you say, it works reasonably well for Enterprise vs Project repositories, but as I said in the OP, we're talking about a distributed Enterprise Repository.

Paolo

[Dah Sra]

While the ability to link to disparate external providers (such as Jira) is enticing, our interest is, for the present, limited to being able to "integrate" a number of EA repositories

Integration with multiple EA repositories can be done, If all the required repositories are configured in PCS and should map those configured repositories in the Data Providers

]

 

Does that mean it CAN'T be used with local repositories?]

Yes, external integrations can be done only in the server-based repositories configured in PCS.

[Paolo F Cantoni]

Thanks, Arshad,

By "local" repositories, I meant "on-premises"; my bad.  However, you have confirmed that on-premises server-based repositories are viable.

Can a user update the external item or just view it?  The documentation on the website would suggest only viewing is possile.

Paolo

[Uffe]

Hi Paolo,

Can a user update the external item or just view it?  The documentation on the website would suggest only viewing is possile.

According to the API documentation, the SBPI has only very limited create/update functionality so you couldn't make any meaningful changes to an external repository this way.
That assumes, of course, that the PCS actually uses the SBPI and not some unholy hidden API.

/Uffe

[Dah Sra]

 
Can a user update the external item or just view it?  The documentation on the website would suggest only viewing is possible.

Yes, you can update all the external items and their properties (the properties must be configured and created while creating the external items.

[Paolo F Cantoni]

 
Can a user update the external item or just view it?  The documentation on the website would suggest only viewing is possible.

Yes, you can update all the external items and their properties (the properties must be configured and created while creating the external items.

Thanks, Arshad!

Does that mean that the external item behaves just like a normal item, but it's stored externally?  If so, how can a user determine whether the item is local or external (other than -perhaps- via the browser)?

Paolo

[Geert Bellekens]

Paolo,

I think you might be expecting too much of this.

As I understood it, it basically creates a proxy element in your browser.
The details of this element are then synchronized with the external tool.

In this case it seems like EA itself is the external tool.

Geert

[Paolo F Cantoni]

Paolo,

I think you might be expecting too much of this.

As I understood it, it basically creates a proxy element in your browser.
The details of this element are then synchronized with the external tool.

In this case, it seems like EA itself is the external tool.

Geert

Of course, Geert, I am (expecting a lot).

I don't want to have to investigate this option unless it's going to be what we need.

Simple use case:
Two repositories "A" & "B" a third repository "C".  Both A & B have C as an external repository.  Element CC in C is available in A & B.  I make a change to CC in C - do A& B see the change?
I make a further change to CC in A, will C & B (eventually) see the second change?

Can anybody provide a definitive answer?
Paolo

[Eve]

Have you actually read the documentation? If you have been using a Package transport you will not get equivalent functionality using this feature.

By default you will get an "external reference" element. You can configure mappings for specific types, but you will not get a 1..1 mapping of types even for an EA linkage. There's no structure created and you can't select anywhere that all elements should be linked.

Once individual elements have references created you can manually push or pull changes to those elements, it's not automatic except that selecting an element will query the external system to show you the properties that it is exposing.

[Paolo F Cantoni]

Have you actually read the documentation? If you have been using a Package transport you will not get equivalent functionality using this feature.

By default, you will get an "external reference" element. You can configure mappings for specific types, but you will not get a 1..1 mapping of types even for an EA linkage. There's no structure created and you can't select anywhere that all elements should be linked.

Once individual elements have references created you can manually push or pull changes to those elements, it's not automatic except that selecting an element will query the external system to show you the properties that it is exposing.

I tried to read the documentation, but it raised more questions than it answered.  Hence my queries.
As with any documentation, even the stuff I write, if you know the subject the documentation makes sense and is often reasonably clear.  However, if you don't understand the subject...  As you're aware, there's been some discussion on Sparx EA documentation by others of late.

For example, above, it isn't clear that types and elements are the same things. Are they?  I suspect not, but it's not clear.  I can understand requiring individual elements to be mapped (and even packages), but whole types (perhaps randomly distributed within the external repository) - doesn't sound useful.

I'm trying to adopt a specific type of strategy.  Not "how soon can I find out if this fits my bill", but "how soon can I eliminate it as NOT able to meet my needs".  I, like many "old hands", have (effectively) wasted a LOT Of time and energy to try to get something working that ultimately wasn't suitable due to various reasons.

So, is my use case supported it not?  From what you said, changes are pushed to the external repository on change but are not visible in the (other) dependent repository until the element is queried again in that one.  If that's correct, then it's not quite my use case, but it goes part of the way

Paolo

[Eve]

"how soon can I eliminate it as NOT able to meet my needs"

I can't answer that because you haven't expressed your needs. All I really see is this.

sharing certain vertices, arcs and viewpoints.  We have been using package transport to date, but this doesn't really scale.

I've already said that you won't get something equivalent to package transport. The goal is to provide an EA element that allows you to see what is in that external system, not to recreate the model defined by that external system. It's designed around a use case like "I have a set of requirements specified elsewhere that I want to reference from within my model."

Based on the (very little) information you have provided about what you want, I believe that this will do nothing to help you. So what's the problem with the various package sharing functions?

[Paolo F Cantoni]

"How soon can I eliminate it as NOT able to meet my needs"

I can't answer that because you haven't expressed your needs. All I really see is this.

sharing certain vertices, arcs and viewpoints.  We have been using package transport to date, but this doesn't really scale.

I've already said that you won't get something equivalent to package transport. The goal is to provide an EA element that allows you to see what is in that external system, not to recreate the model defined by that external system. It's designed around a use case like "I have a set of requirements specified elsewhere that I want to reference from within my model."

Based on the (very little) information you have provided about what you want, I believe that this will do nothing to help you. So what's the problem with the various package sharing functions?

Thanks for clarifying, Eve,

As I said in the initial post it, doesn't scale (for us).  What I didn't say (and this may well be the source of confusion) that we've found that many of our packages (containing items) are too large.

We have separated our items from the views.  At the enterprise scale, we may have literally hundreds (if not thousands) of items of the same type (for example databases or application systems or organisational units etc.)

We group all our items by type and, if required, break them into alphabetic subfolders (for some even that's not enough and we're thinking of two-level alphabetic).  We are finding that we need to be able to share only a very small portion of these item folders.  At any time only a tiny proportion of these items are being changed, so transporting whole branches (of this size) is counter-productive (as well as, effectively, impractical).

There's nothing wrong with transporting packages, so long as the packages are small and self-contained.  Ours are neither (in many cases).

So, as you can see, I'm NOT looking for package transport. I could entertain package sharing where the external items are available to the local model and changes are pushed/pulled as required only for those external items referenced in the local repository.

Hopefully, I've explained our needs a bit better.

Anyway, based on the discussion so far, it seems this is not the solution we're looking for.

Paolo

[Geert Bellekens]

Paolo,

What if each element was in its own package?
In that case you would be able to share individual components between different models.

Have you considered this approach?

I know it's a bit unorthodox, but it might just work.

Geert