Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on January 08, 2021, 04:41:17 pm
-
From Integrate Data from External Providers (https://www.sparxsystems.com/enterprise_architect_user_guide/15.2/model_repository/integrate_external_provider_data.html);
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 (https://www.sparxsystems.com/enterprise_architect_user_guide/15.2/model_repository/pcs_plugins_config.html);
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?]
-
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
-
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
-
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
(https://i.ibb.co/bPC516j/image.png)]
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.
-
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
-
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
-
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.
-
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
-
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,
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
-
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.
-
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
-
"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?
-
"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
-
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
-
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
You jest, surely, Geert! ;) The administrative overhead would be worse than writing our own synchroniser (and on going). We're talking several hundred to several thousand shareable items in tens of thousands of items in an enterprise repository. As the overseer said, in "Cool hand Luke", "Id cayn't be durn".
Paolo
-
I don't really see the overhead.
Surely your version control system can handle thousands of files.
Putting each element into it's own package, and adding that package to version control can be automated with a little script (I have some examples if you want).
I'm guessing EA won't have an issue with this either.
And if you only version control the lowest package level, you could import a random selection of elements into any given repository.
Or is it the dependency management that you are afraid of?
The fact that you need to import all dependencies of an element into a repository as well if you want to be able to update an element in that repository and not loose any relations in the process?
I can imagine that being a challenge regardless of the chosen solution.
Geert
-
I don't really see the overhead.
Surely your version control system can handle thousands of files.
Putting each element into its own package, and adding that package to version control can be automated with a little script (I have some examples if you want).
I'm guessing EA won't have an issue with this either.
And if you only version control the lowest package level, you could import a random selection of elements into any given repository.
Or is it the dependency management that you are afraid of?
The fact that you need to import all dependencies of an element into a repository as well if you want to be able to update an element in that repository and not lose any relations in the process?
I can imagine that being a challenge regardless of the chosen solution.
Geert
(my emphasis)
Yes, Geert, I see the emphasised issue as the essential problem.
We're currently looking at a model for the design of this process. If the model shows it might be feasible, we'll have a look at possibly implementing.
As Eve has said, we need to clearly enunciate our requirements and constraints. This we are also modelling to clarify our thinking (about ANY solution) and guide our design.
For example, I don't think we'll need to import ALL dependencies, but only the relevant ones (that is only those in the target repository - we hope. But the detailed analysis will reveal if that's the case. Nevertheless, it doesn't reduce the complexity much.
I agree one item per package is not (really) a performance issue for EA, but it is a significant human loading issue.
Anyway, we'll plug-on with the modelling to see what we think is necessary.
Paolo
-
I guess you already looked into the Reusable Asset Server? I thought that yours was the use case it was designed for? Or are you more about partitioning the rep into bits ?
-
I guess you already looked into the Reusable Asset Server? I thought that yours was the use case it was designed for? Or are you more about partitioning the rep into bits?
Hi Ian,
I thought RAS was a unidirectional mechanism, you could only edit in the remote repository and once imported into the local repository can only be compared with the remote version.
That's not my use case. My use case is element based, not package based, I guess my use case IS more about partitioning the repository (but not on a package basis).
More formally, it's about creating a distributed "virtual" repository where some elements are shared between a number of physical repositories.
We're still working our way through formalising the requirements in a model using Requirements, Constraints, BPMN diagrams etc (as time and resources permit ;))
Paolo