Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Markus Bauernfeind on October 18, 2017, 07:07:14 pm
-
This might be a basic question, but I could not find the answer. I know how to do it in the GUI, but in an Add-In?
I have an Activity Element and an Action Element. How do I connect them via a CallBehavior?
Thank you.
-
Good question. The API does not seem to expose it. I'll have a look.
q.
P.S. t_document.classifier_guid corresponds to the operation's guid.
-
If it's an operation, that would be a CallOperation action, not a CallBehavior one.
Also, t_document? I think you might be responding to a different post there. :)
The referenced behavior in a CallBehavior action is a simple classifier, and is set like any other simple classifier:
action.ClassifierID = activity.ElementID
Semantically it doesn't have to be an activity, any behavior element is accepted. In reality, I'm pretty sure EA will accept any classifier.
CallOperation actions, on the other hand, have no classifier ID. They do have a classifier GUID. If you look in the database, these are different columns. For simple instance/classifier relationships (like the one above), the classifier ID and GUID refer to the same classifier element, but for things like CallOperation actions, the ID is 0 while the GUID contains the GUID of the operation.
So the classifier ID must (apparently) always refer to another element, while the classifier GUID can refer to other stuff as well. The API doesn't expose Element.ClassifierGUID, and it's not in Element.CustomProperties either. I think the only way to set this might be Repository.Execute().
/Uffe
-
So, there are two things to do. One is to set the classifier as above. This can not be done with the API, but only directly in the database. The second is to add a couple of CustomProperties which, according to the help, are "Currently only editable from the user interface.". Instead you can create an entry in t_xref with
Name="CustomProperties"
Type="element property"
Description="@PROP=@NAME=kind@ENDNAME;@TYPE=ActionKind@ENDTYPE;@VALU=CallOperation@ENDVALU;@PRMT=@ENDPRMT;@ENDPROP;"
Supplier=<guid of the action>
Good luck.
q.
P.S. Uffe is right. It's t_object.classifier_guid (I was working on t_document for a request from Geert). And it's a CallOperation I'm talking about (drag operation onto diagram).
-
This looks right to me, but the OP was talking about CallBehavior actions. They don't refer to an operation but to an activity (or other behavior, like an interaction), so setting the classifier ID is all you need to do in that case.
/U
-
For CallBehavior it's similar. t_object.classifier_guid has the guid of the StateMachine or whatever is in place. t_xref differs in
Description="@PROP=@NAME=kind@ENDNAME;@TYPE=ActionKind@ENDTYPE;@VALU=CallBehavior@ENDVALU;@PRMT=@ENDPRMT;@ENDPROP;;"
q.
-
Sorry, but I do not understand. I am coding it in C#.
I have two Variables
Element action;
Element activity;
What would be the code?
-
On that level? Your magic hand moving the mouse.
q.
-
I am sorry, but I really do not know, what to do with the code you provided. :(
-
If your action is a CallBehavior action, you just need the code I posted up above. It only gets complicated if you're working with CallOperation actions.
Plus you need to call Element.Update() at the end of any set of changes you make, since that's what writes the changes back to the database.
/U
-
Uffe, that's not correct. The above will create an instance, which is something completely different.
q.
-
I am sorry, but I really do not know, what to do with the code you provided. :(
In other words: you can not do that easily. The API provides nothing to do it. You need to dig into the underlying database and how to deal with it. Only then you can use what I posted above.
q.
-
Hello Markus,
To bring you to the right track.
The API seems to have no method, that allows you to make an action a call behavior action or at least to define by API what it calls by that action.
So, if you do not have an API, you have to change your model by changing DB content directly.
By doing so, you will see some ugly things in the EA DB design like the stuff above, what shows that the relevant data for your issue is stored as some kind of structured text in a description field of a db table.
-
Hmm.... I have tested what I posted and it does work. It does not "create" anything. It links an instance-type element (eg an action) to a classifier-type element (eg an activity). That is how EA links CallBehavior actions to activities: the action is an instance of the activity.
I have an Activity Element and an Action Element. How do I connect them via a CallBehavior?
The OP said you had an activity element and an action element, which you wanted to connect. If that is the case, you set the action element's ClassifierID to the activity element's ElementID. That is it. The code I posted will do exactly that, but it doesn't include the Update call you always need to issue.
If the problem is that you don't know how to create a CallBehavior action, then that's not the same thing at all. Then you need to create a CallBehavior action first. But again, once you've done that, setting its classifier ID is all you need to do.
/Uffe
-
Uffe, what you describe is what you get when you press Ctrl-L on the Action and select a classifier. Do that for an Action of your choice. Now from the menu create a new Action and select CallBehavior. It will ask for certain elements (e.g. a StateMachine) you can assign to the behavior. Now look at both elements and you will see the difference.
q.
-
You can't "assign" an element "to the behavior". That makes no sense. The behavior is the classifier (activity, state machine, etc), and you specify which behavior a CallBehavior action calls by simply setting its classifier ID in the way I described. This yields the same result as setting it through the GUI, either when creating the action or hitting Ctrl-L later. The Select Element dialog narrows the type of classifier you can pick based on the action's type, so you'll be able to select different classifiers for AcceptEvent and CallBehavior actions, but for one type of action there's no difference between selecting on creation and (re-) selecting later.
The OP asked specifically about linking an action to an activity. That is only semantically valid for a CallBehavior action. Now, since an action is an instance type, you can of course always link any action to a classifier -- even if it is an atomic action, or a CallOperation action, or whatever. But that's beside the point: only CallBehavior actions can be linked to activities in a semantically valid way, and the OP did ask about linking an action to an activity. All you need to do for that to work is set the classifier. If the action is not a CallBehavior action, the question is meaningless.
Put another way: for CallOperation actions there is a difference between setting the classifier and setting the operation, but for CallBehavior actions there is no difference between setting the classifier and setting the behavior. They are the same thing.
/U
-
Hmm. You are (almost) right. It seems I got mixed up with both (I don't use it that often). However, there's a little difference. The menu-created CallBehavior has that little trident icon. Just setting the classifier does not create this icon. It will probably only appear if you create the t_xref entry.
q.
-
The trident, and if someone could explain the visual logic of that thing to me I could go to my grave a happy man, comes from the fact that the action is a CallBehavior, not from whether it's linked to an actual behavior. You can verify this by changing the action kind (properties - advanced).
So if the trident's missing, I'd say that's because it's a different kind of action.
/U
-
Yes, sure. I just thought that icon should be there to identify the Action as actually being a CallBehavior. Anyhow, I'm leaning in towards areas I have not touched in recent times. I had only been looking at technical details in this thread.
q.
-
and if someone could explain the visual logic of that thing to me I could go to my grave a happy man
I believe the trident is supposed to look like one of those call trees that we used to draw in the days before UML.
-
Icons in the Windoze world: The Diskette. I don't remember when Apple abandoned it, but it was probably the last millennium. I guess even the Windoze guys don't remember what the blue square is standing for. Still using that, though.
q.
-
Icons in the Windoze world: The Diskette. I don't remember when Apple abandoned it, but it was probably the last millennium. I guess even the Windoze guys don't remember what the blue square is standing for. Still using that, though.
Circa 1998. Before that they used to boast that their firm floppy was much better than floppy floppies.
But then again when was the last time you "dialled" anyone. Millennials probably never have. Language contains all sorts of apparently dead concepts. Like why we call you lot Germans https://www.youtube.com/watch?v=sQPYkdp_7Vc
-
Yes, YOU call us German (man with "ger", which is a lance in English). WE call us Deutsch. Anyhow, social concepts in language may live longer. IT is much faster. Using dead concepts in IT is a no-go.
q.