- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎21-12-2022 03:58 AM - edited ‎21-12-2022 04:38 AM
Hi,
For an Application Environment object, HOPEX allows a user to create multiple diagrams of type "Application Environment".
For example, even if I have already created one Application Environment diagram, I can create another.
What is the intended use case for this ?
The way I see it - you run into a problem with this when you try to display some automated reports - like "Graph of interactions of an agent"
An environment is a context (i.e. current or target state, usage of the app for a specific region or line of business etc..)
But in "Graph of interactions of an agent" report - when you select the application environment object - you will get interactions from all the Application Environment type diagrams.
To me - the only use case I would see fit to create multiple structure diagrams for an Application environment is if following conditions are true
- Application Environment object is created for a specific context (e..g current state of an application)
- A single structure diagram (i.e. Application Environment diagram) is too large (i.e. too many interactions or partner objects).
In that case, I might create multiple diagrams. For example, lets assume the application serves large group of consumers - some via batch and some via APIs
- First structure diagram - "Batch consumers"
- 2nd structure diagram - "API consumers"
Then, the "Graph of flows of agents" would show ALL interactions for that environment/context - which is probably OK.
But, even as I write this - I still think a better practice would be to create two separate Application Environment objects for the current state of the application, and have a single structure diagram.
Curious if other have encountered question and what you think.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎29-12-2022 05:20 PM
That is very helpful. Thank you again!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎29-12-2022 05:07 PM
Hello,
Regarding report about flows, the "context" proposed in the filter box of the report are the scenarios of flows in which there are flow(s) implying current object (application or other). And by default, scenarios of flows have the same name of the described object, so you may think that you see the environment in the box when it is the scenario of flows of the environment.
As a consequence, a context for an application can be a scenario of flows of an application environment or an application system. Same principle for other "software building blocks" like application system, Micro-service or It Service.
Regards,
Patrick Bessodes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎29-12-2022 04:34 PM
Thanks very much @PBessodes .
Just one follow-up question:
Is there any documentation on what can be selected in the "context" menu on the "graphs of flows of an agent" ?
I know "Application Environment" is one context. But, what else does hopex consider "application context" that can be used as the "Context" filter?
Or, is it _only_ the "Application Environment" objects that can be selected ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎28-12-2022 11:59 AM
Hello,
Mega point of view is the one you described:
- Environment is a context (region, subsidiary/company, macroprocess, business line ...) which defines the perimeter of what will be modelled (how an application integrates itself with others).
- Diagram does not contain any context. It is simply a view on the described object (here an environment) mainly for communication purposes.
When using "Graph of Interaction of agent" or "Graph of Flows of an agent" report, you can define the context(s) you want to see but not diagrams as their content is free and depends only on the communication will behind it.
Patrick Bessodes.
