[00:00] The enterprise administration module allows you to view agent information from within the designer as well. I'm here in a project I created on my controller gateway, and within it I have access to some system tags for each agent connected. These can be found within the system tag provider, so I'll change my tag provider from default over to system. If I expand the gateway folder, you'll see a folder for both eam and gateway network, which contain tags holding data for my connected agents. The singular agent I have connected has a folder for it within gateway network. Expanding this folder provides two memory tags showing if the agent is available on the network and the last communication time. If I drill down the eam folder now, we'll see I have another folder for my agent containing even more tags. These include information about the group the agent is in, the name of the agent, if it is approved, connected or running, and even the version of the agent.

[01:08] We also have access to this metrics folder, which provides information about agent databases, error logs, current sessions, as well as CPU and memory usage. Keep in mind that the database folder is created if the agent has a database connection. It doesn't have to be active as mine is not here, but it does need to exist. Now, since I'm in the designer for my controller, I also have the ability to send tags to connected agent gateways. I'll navigate back to my default tag provider to see this. Let's say I wanna send this test tag one to my agent gateway. If I right click on the tag, you will see an option for eam in the popup menu. Highlighting eam will allow me to send tags to different servers. I'll click on it here, and this will open up the send tags to servers menu. We can see my test tag one pulled in as the selected tag we want to send.

[02:03] Additionally, you could drag in more tags to this window. I'll go ahead and do so for test tag two. On the right hand side of this menu, we can specify which tag provider the tag should move to. In this case, we are choosing the default tag provider. Next, we have the tag collision policy, that would take effect if the same name tag exists within the agent. In this case, we can set it to abort sending the tag altogether or overwrite the tag in some way. For more information on tag collision policies, refer to our user manual page tag, export and import. A link to this user manual page has been added below the video. If your agent is using an ignition version prior to 8.1.39, these tag collision policies will be ignored and your agent tags could be overwritten if a collision exists. Moving on, we have a selection for which agents we want to send tags to. I only have the one agent available. However, if you had more agents, you could send the tags to all of them or a subset by checking them off.

[03:03] I'll go ahead and click okay here to send a copy of test tag one and two to my agent, and I'll click yes on the confirmation window. Now I'm presented with the results of my tag send. The message is telling me that remote tag editing is not allowed in the default tag provider of the agent. This can occur if your agent's tag access is not set to allow tag edits. To fix this, I'll navigate to my agent's gateway where I'm already in the service security section of my config tab. I need to adjust tag access on my default security zone as it's the only security zone defined. However, you can always create a new security zone to handle tag access. So I'll click edit here and I'll scroll down to the tag access section. Right here, on the default provider access level, we can see it's set to read only, so I'll change this to read, write, edit and I should be able to send the tags with eam. I'll go ahead and click save and navigate back to my designer.

[04:03] I'll close the results message and attempt to send one more time. Again, I'll right click on test tag one and open up the send tags to server screen. I'll leave the tag provider and collision policy as is and select my agent. Finally, I'll hit okay here and reattempt to send. Eureka, We have a success message telling me the tags were received, and we can see my controllers test tag one is still here, so that means I only sent over a copy of the tag. Beyond tag data, I can also gather agent information using property binding functions to pull in agent status or history data. I'll navigate to my vision window named agent monitor, to show this off. On my window, I have a power table component and I'll click on the chain link icon to set the binding for its data property. On the property binding screen, I'll select the functions tab. If I expand the binding function selection here there is an enterprise administration section containing the functions agent status and agent history. Both of these functions return a data set, which is why I can use it on the power table.

[05:08] I'll select agent status first. The function arguments here allow you to specify results based on agent name, group name, or connection status. I'll leave these blank for now, which will pull information for all agents. Finally, I'll click okay to populate the table. The dataset now represents similar data to what we saw with the agent tags. Again, we have the agent name, agent group, last communication, if the agent is connected and running and license and version. I'll click on the chain link icon again and switch over to the agent history function now. This function does expect a start and end date, so we do need to specify those. And we can filter further by agent name, group name, event levels of normal, warning, error or none, and a limit of results to show with the value of zero showing all results. These can also be bound to different tags or component properties.

[06:05] I'll go ahead and click okay, and the dataset will populate with the data from the agent events table. Agent events include gateway task results, abnormal health statistics, and agent communication status events. We can see I have things like the event ID, agent, event time, event category, and type, and the event level. In addition to these binding functions, eam also provides scripting functions to create an agent status or agent history dataset. I'll utilize scripting on this results button to change our power table's dataset. First, I'll remove the binding on the power table by going back to the data property binding and clicking this no binding button, then okay. If I right click on the button, I can access its script editor. I'll choose an action performed event handler to trigger the script when the button is pressed and I'll go over to this script editor tab. All of these functions are system functions, so I'll start by typing system, then dot eam dot.

[07:06] To give us the eam functions. I'll select query agents status first. This function lets us pass in group and agent IDs as well as a boolean to see if the agent is connected. I'll clear these to return all results. I'll assign the return data set to a variable called agent status. On the next line, I'll make use of the property selector to write back to my power table's dataset with the agent status dataset. Within my root container, I'll grab my power table's data property and I'll set it to my agent status dataset and click okay. If I go into preview mode and click my button, the power table will populate with the same data we saw from the agent status binding function. I'll go back to my button script to use the agent history function. Then I'll change query agent status to query agent history. Again, we can pass in a group or agent id. I'll clear out these arguments and I'll update the name of my dataset to agent history and click okay.

[08:13] When I click the button now the table populates with the agent events table data again. For the last two available system functions, I'll open up the script console to show those off. I'll paste in the script here for the system dot eam dot get groups function. This function returns a list of all agent groups as strings, and my script is printing out all the elements of that list named groups. When I click execute, the default group prints out as I only have one group defined. The last function I'll discuss is the system dot eam dot run task. This function takes the name of a task as a string and runs the task. In order for this to work, you do need a task defined on your controller gateway. I have a task called restart agent, which will restart my agent gateway, so I'll go ahead and pass the string restart agent to my function.

[09:07] I'll click execute here and I'll bring up my agent gateway into view. Let's refresh the screen to see the agent restart, and now we see the agent restarting, so my run task function call was successful. Now, if you wanted to use the run task function from the client, you do need to enable a role-based permission within the project. Going back to my controller design space, I'll click on the project here to access the project properties. Looking in my vision permissions, there is an eam task execution permission you can enable for specified roles. These functions as well as the tags in the enterprise administration module give us all the necessary tools to create agent related clients and scripts.