Agents

Agents run periodically and execute code specified by the user.

To set up an agent, there are two necessary steps:

• Under Design → Code, create an Agent Library and add your code to the on_schedule function.
• Under Design → Proto, select the Proto you want to use and add corresponding the Agent Library

1. Create a Proto with a DateTime Field and a Text Field. Copy the key of the Text Field.
2. Create a user profile with rights to edit the proto created above but without Environment Administrator rights.
3. Create an Agent Library, specify the user created above as context user and copy the following code. Replace the value of fieldkey_status_field with the key from above.
4. Create a Proto for parameter values with a Text Field, copy the key of the Text Field and replace fieldkey_parameter_value with that key. Create a parameter Card with this Proto, copy the key of that Card and replace cardkey_parameter_deadline_reached with that key.
5. Add this Agent Library to your Proto.
6. Based on this proto, create some cards where the date lies within the next 60 minutes. Wait one hour.
7. The value in your Text Field should have been replaced by Frist abgelaufen.

function agent_library() {
    var fieldkey_status_field = '3b47a5fe-894d-4580-bc0c-563aa83d9a02';
    var cardkey_parameter_deadline_reached = '9e13a5b0-97d5-405e-9f50-8a2f808cf541';
    var fieldkey_parameter_value = 'a9a8143f-ad68-4df1-d57b-d8df1569c83b';
 
    // Make sure that this function does not return until all operations and JSON-API requests are completed / fulfilled.
    // We recommend to use await / async syntax: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async_await 
    // * card [object]:    The card that triggered the agent
    // * cookie [string]:  A valid cookie that can be used.
    // * axios [object]:   An axios object. You can use e.g. axios.get() and axios.post() for API requests
    // * baseurl [string]: Contains the base url needed for API requests
    // * appname [string]: Contains the application name
    // most URLs needed for API calls are structured like baseurl + 'api/v2/apps/' + appname + (...)
    // return value: A boolean. If set to true, it will save the current card
    async function on_schedule(card, cookie, axios, baseurl, appname) {
        // Here is an example for an authenticated axios GET request:
        try {
            var response = await axios.get(baseurl + 'api/v2/apps/' + appname + '/cards/' + cardkey_parameter_deadline_reached, {
                'headers': {
                    'Cookie': cookie
                }
            });
            console.log('axios GET request finished');
 
            var loaded_card = monkey_patch_card(response.data.result);
            var loaded_message = loaded_card.get_value(fieldkey_parameter_value, 'Frist abgelaufen');
            card.set_element_value(fieldkey_status_field, loaded_message);
 
            return true;
        } catch (e) {
            console.error(e);
            return false;
        }
    }
 
    return {
        on_schedule: on_schedule
    };
}

Agents are by default checked every hour (this can be modified for your environment, please contact the Protogrid Operations Team). If any DateTime Field on a card has a smaller value than the current time and the Agent has not yet run since that time, the Agent gets triggered and the code in the Agent Library is executed in the context of this card. For Date-Only Fields, the time taken into account is determined by the value of 'Time Offset Value for Periodic Agents' in the Environment Properties (defaults to 03:00 GMT).

Agents run in the context of a specific user profile which must not have Environment Administrator rights. This user's password is automatically reset during the execution process. So this user profile shall only be used for agents and not for physical users. All agent executions are logged in the agent_log on the respective card.

While an agent is running in the context of a specific card, it is also possible to load and save other cards by calling the JSON API endpoints using axios. A valid axios module is given in the on_schedule function. Agents have a global runtime limit (usually one hour). If you want to restrict this limit for certain agents, you can do so by entering the desired maximum runtime (in milliseconds) in the Agent card. After reaching the runtime limit, the code will terminate instantly and the next card will be processed. The process will not be started if the time until the next agent check is less than the maximum runtime.

The on_schedule function should return a boolean. If the boolean is true, the card that triggered the agent will be saved.

In the following, we have compiled some recommendations based on our experience for high stability, performance, reliability and maintainability of backend code that performs calculations on a larger number of Cards (i.e. more than 100):

1. It is recommended to use views of dedicated Search Dialog Boxes for retrieving the needed source data for calculation code. Do not use multi column indexing views for backend code.
2. Note: Use multi column indexind views at all only if the free combination of several filters is required in the user interface.
3. Write to as few Relation Fields as possible in the code. Do this only if it is needed for the user interface (e.g. for filtering TableViews). Do this only on Cards that are rarely/never edited. Do this only on Cards that do not (already) have a large number of Relating Cards.
4. Procedure if the calculation code requires a “relation” that does not need a Relation Field in the user interface: Use a Text Field instead of a Relation Field. Write the key of the relation to this Text Field with an individual prefix (important!). Use a Text Filter or a dedicated Search Dialog Box to retrieve Cards with the desired relation.
5. If editing or deleting a Card in the user interface subsequently to calculation has to be prevented, this can be done in both cases by restricting the editing rights (roles at Proto and/or Card level).
6. Read/load as few specific/single cards as possible. Work with views whenever possible. Use “include_cards” - but only if necessary and on as few view rows as possible. Do not hesitate to contact Protogrid Customer Support proactively in case of special requirements (e.g. certain values needed in the value of a view row or special reduction views needed).
7. Analogous to the previous point, write as few specific/single cards as possible. Whenever possible, save several cards together. You can use the Endpoint /api/v2/apps/<app_name>/cards with a list of Card objects in the POST body.