Hello Wayne,
this is a very interesting information!
If we have publishable docs in IS and create a trigger with server side filtering, then some corresponding objects are created in UM.
Now, assume that we’ve changed the trigger (changed the filter condition). When we deploy the trigger to a runtime (IS), two things (at least) have to change (in my view):
- The trigger definition in IS
- Something (don’t know exactly what) in UM – since the filtering is done in UM
And now the question: Does your statement about deployment of UM assets mean that by deploying (repository based) only the trigger (as an IS asset) we will NOT change UM to the desired state? I.e. that we also have to explicitly deploy assets of type ‘UM’?
I’ve always assumed that the deployer (here I mean the system component) would change all system components as needed so that everything works after e.g. a trigger (IS asset) has been deployed. But this assumption would be wrong if we have to explicitly deploy UM assets along with the trigger (or some other IS assets, e.g. publishable docs).
The same situation would arise when deploying a process model (and its generated package): the subscription or the transition trigger might have been changed so that UM has to be updated as well. Will it be updated by deploying only the generated package?
Could you please clarify on this?
Thanks a lot!