I have the following session relevance wherein we are trying to get list of actions and each targeted servers to see if their
((id of it, name of it, value of results from (bes property “Service Name”) of it) of computer of it, (id of it, name of it, name of issuer of it, time issued of it,start date of it,start time_of_day of it, end date of it,end time_of_day of it) of action of it) of results whose ((start time of it > (now-10*day)) AND (status of it as string = “Fixed” OR status of it as string = “Pending Restart” OR status of it as string = “Completed”)) of bes actions whose ((name of issuer of it contains “USER”) AND name of it as lowercase contains “MSRT” as lowercase)
We are able to get actions that already started (actions that already ran) but what we are trying to get is the actions that are scheduled in the future. We wanted to make use of the session relevance to perform QA on the actions that were already created and are supposed to run in the next days so we can verify if their time/date of execution would be correct.
I am thinking maybe this has something to do with the actions not being in the action results table in the DB? I do not have access from the DB yet to check.
If you remove this condition, you should be able to see actions that are scheduled but have not yet started. However, a key requirement is that at least one server from the targeted list must be in a state other than “Not Reporting”
This is because actions only appear in the results table when at least one targeted machine has reported back. Therefore, for a scheduled action to be visible, at least one of the targeted devices must be actively reporting and have started evaluating the action.
Thanks! That helped me move further. The condition for the start time and the results for the start time and all the other parameters that are in the results table were removed and I was able to get the actions from future dates.
I am now down to this relevance:
((id of it, name of it, value of results from (bes property “Service Name”) of it) of computer of it, (id of it, name of it, name of issuer of it, time issued of it) of action of it) of results of bes actions whose ((name of issuer of it contains “user1” OR name of issuer of it contains “user2” OR name of issuer of it contains “user3” OR name of issuer of it contains “user4” OR name of issuer of it contains “user5” OR name of issuer of it contains “user6”) AND name of it as lowercase contains “02/20” as lowercase)
My problem now is if I add the parameters “start date of it,start time_of_day of it, end date of it,end time_of_day of it”, it would return Singular expression refers to nonexistent object error. These are the parameters Start/End time/date in Execution tab when taking action. Do you know if these are also in the results table?
I am able to get results for these parameters when using them with actions that have already results.
They don’t exist until the action runs, so you need to ‘error-proof’ them. You can use a pipe to provide a default value for those properties when they generate an error, e.g.
(start date of it as string | “None”)
The error/pipe value has to be the same type as the value you’d get from the inspector, which is why the example above casts the date as a string, and the parentheses will keep the pipe in context.
So these parameters can only be queried once the action have already started? It would make more sense that the “start time of it” would not exist because this is the actual time the action started from the machines. But it is quite strange that the start/end date/time would need the action to start first before querying them. But if that is how it works then I think that’s fine.
We are actually trying to get the start/end date/time of the actions prior to the schedule of when it should be running so we can QA if they are set to proper start/end date/time. Maybe the inspectors I am using have a counter part from the action table rather than the action results table?
I didn’t read your post closely enough.
To clarify, the properties you listed
start date of it
start time_of_day of it
end date of it
end time_of_day of it
are properties of bes action, and they can be present or not depending on whether you use those options in the Execution tab of the action.
The similar properties
start time of it
end time of it
are part of bes action result, and they will be present or not for each computer’s result depending on whether the action has run yet on that computer.
The pipe technique will let you deal with both, but you’re right that the action start/end constraints should be available as soon as the action is issued (regardless of whether any computers have results).
