Can some one please explain conceptual difference between Include and Exec for Library actions? And what is usage scenario for both of them?
Thank you in advance.
I use Include Library Action primary for my admin restricts. So any Server Action that would be used by an admin will have a security restrict and a security identity.
By having an Include Library Action, I don’t have to repeat adding the two steps to every Server Action and if I should ever need to change it, I would only have to change the Include Library Action.
Include Library Action
Server Action using the Include Library Action
With the Execute Library Action, I save time by not having to repeat steps that I use quite often. For example, @Hyperbytes has a video about creating Search Engine titles and descriptions via a database. Because I do not want to repeat the insert actions over and over for every page, I use the Execute Library Action and instead of setting $_POST items, I set $_PARAM items in the Execute Library Action.
When I add the Execute Library Action to a Server Action, it provides me with slots where I can add the $_POST items being sent from a form. Since I use this repeatedly for various server actions, I can save time.
This may be a basic example, others may have more advanced examples they can share.
5 Likes
Include: On runtime, the steps inside library action, will get added to Server Action, in place of the include step. So steps below include can directly refer to those steps for dynamic binding.
And the include library action itself could be configured to use bindings from steps above the include step. Doing this restricts re-use.
Exec: On runtine, exec library action gets executed like an API action would. You have to set parameters in this steps, based on what you define in the library action’s $_PARAM section. In the steps below exec, you can access only the steps which have output enabled in the library action.
2 Likes
Bit confused, i do the insert via API Workflow Globals action using the page’s own data to construct the SEO content so it effectively does the same as a library action, runs automatically with every API call, no need to repeat code.
Right, I customized that part of what you did I have navigational layers of main pages and sub-pages with query parameters and did not want to create a complicated series of conditions in Globals. 
But you deserve the credit because otherwise, I would have had to figure something else out to achieve what I wanted.
Another illustration of our need for CASE structures in API actions!
2 Likes
Just as a slight side tip, I put the Security Identity into the Globals file so it’s available across the entire project.
Can you please explain this in details?
No problem. Click on Globals:
and then add the Security Identity action in there:
This means the identity is available in all API action files. And because the Global ooption is ticked, the identity value is available in all Server Connect components:
1 Like
That’s very interesting.
Didn’t know that.
Thank you!
1 Like
You can put other actions into Globals so they appear across the entire project. Things like a Query Single for the details of the logged in user, for example. Globals transformed the overall structure considerably when they introduced them a few years ago.
1 Like
1 Like