En esta lección, hablaremos sobre ámbitos y referencias. Esto le ayudará a hacer que las reglas y acciones sean reutilizables, así como a acceder a los datos de todo el componente y a gestionarlos.

Hay dos ámbitos en los que puede declarar reglas, acciones y almacenar datos:

  • paso: Cada paso de un componente tiene su propio ámbito. Las reglas, las acciones y los datos definidos aquí no están disponibles en ningún otro lugar.
  • Flujo de trabajo: Todos los pasos de un componente tienen acceso a las reglas, acciones y datos agregados al ámbito del flujo de trabajo.

Además, hay tres ámbitos disponibles para almacenar datos:

  • raíz: Todos los componentes de un flujo de trabajo tienen acceso al ámbito raíz. Esto se puede utilizar para pasar datos entre componentes.
  • user_session: Mientras el usuario no cierre la sesión, se podrá acceder a los datos almacenados en el ámbito de user_session incluso después de finalizar la ejecución del flujo de trabajo (por ejemplo, desde dentro de otro flujo de trabajo o al ejecutar el mismo flujo de trabajo varias veces).
  • global: Mientras la aplicación Frontline Workplace no esté cerrada, se podrá acceder a los datos almacenados en el ámbito global, incluso si un usuario cierra sesión y otro usuario lo hace.

Componente de ejemplo

<workflow [ATTRIBUTES]>
    <context> [...] </context>                              \
    <actions> [...] </actions>                              -\<
    rules>                                                 --\ 
        <rule id="menu_button_selection">                   ---\
            <expression>[..] </expression>                   ----\
            <actions>                                       -----|--> Ámbito
                del flujo de trabajo[...]                                       ----/
            </actions>                                      ---/
        </rule>                                             --/
    </rules>                                                -/
                               
    <steps> 
        <step id="stepA" [ATTRIBUTES]>
            <context> [...] </context>                      ----\
            <rules> [...] </rules>                          -----|--> Step scope
            <actions> [...] </actions>                      ----/
            <states>
                <onevent> 
                    <rule ref="menu_button_selection"/>     -------> Hacer referencia a una regla desde el ámbito

                    del flujo de trabajo<regla id="show_notification">           --\<
                        expression>[..] </expresión>       ---\
                        <acciones>                           ----\
                            [...]                           -----|--> Definición directa (aún podría hacer referencia a una acción predefinida)
                        </actions>                          ----/
                    </rule>                                 ---/
                </onevent> 
            </states>
        </step>

        <step id="stepB" [ATTRIBUTES]>
            <states>
                <onevent> 
                    <rule ref="menu_button_selection"/>     -------> Hacer referencia a una regla desde el flujo de trabajo scope
                </onevent> 
            </states><
        /step>
    </pasos><
/flujo de trabajo>

En este ejemplo:

  • Se define una regla con id="menu_button_selection" en el ámbito del flujo de trabajo y, a continuación, se hace referencia a ella tanto en paso id="stepA" como en paso id="stepB" mediante el ref atributo.

Nota: La reutilización de reglas y acciones hace que el comportamiento del componente sea coherente, mejora la capacidad de mantenimiento y minimiza la cantidad de código.

  • Los identificadores dentro de un ámbito deben ser únicos. Puede usar identificadores idénticos en otros ámbitos, pero a menos que tenga una muy buena razón, le recomendamos que no lo haga para evitar confusiones. Si utiliza identificadores idénticos, el orden de prioridad es ascendente: si una regla con id="menu_button_selection" se define directamente en el ámbito del paso, se ejecutará en lugar de cualquier regla predefinida con el mismo identificador en el ámbito del flujo de trabajo.
  • También es posible que tenga reglas o acciones que solo son necesarias en uno de los pasos, pero que son necesarias en varios estados o reglas de ese paso en particular. En este caso, puede definir la regla/acción en el ámbito del paso y hacer referencia a ella de la misma manera.
  • Por último, también puede definir reglas y acciones directamente donde se necesiten. Dicha regla/acción no estará disponible en ningún otro lugar. Si sabe que su regla/acción no se volverá a utilizar, una definición directa puede hacer que el componente sea más legible, ya que no tiene que saltar para ver la implementación.

Nota: Los identificadores deben ser únicos dentro de un ámbito. Si copia y pega una regla o acción existente como plantilla al crear una nueva, un error típico es olvidarse de cambiar el atributo ID. Acostúmbrate a cambiar primero el documento de identidad.

📌Asignación

Refactorizar nuestro componente de elección:

  • Coloque la finish_workflow acción en el ámbito global y haga referencia a ella en la regla
  • Coloque la menu_button_selection regla en el ámbito global y haga referencia a ella en el paso
  • Asegúrese de que el componente sigue funcionando según lo previsto

Descargar componente (pre-asignación)

Ayuda y recursos

Estos son algunos consejos para facilitar un poco el desarrollo de flujos de trabajo y componentes:

Modo de vista previa

Este modo le permite probar inmediatamente los cambios sin tener que publicar el flujo de trabajo. Para obtener más información, consulte la sección Flujo de trabajo de vista previa.

Registros de servidor y cliente

Puede acceder a la FCC y a los registros del dispositivo iniciando sesión con el usuario sysadmin o accediendo directamente a la carpeta UBIMAX_HOME\logs. Los registros del dispositivo se envían al servidor periódicamente, pero puede solicitar la carga inmediata como usuario administrador del sistema.

Notas de la solución

Si aún no tenías todo preparado para el desarrollo, esa debería haber sido la tarea principal para esta primera tarea práctica.

Cabe destacar que, en la definición de la regla, ahora hace referencia a una acción predefinida definida en el mismo ámbito. El orden de las <actions>etiquetas y <rules> no importa para que esto funcione. Este es el aspecto que debería tener el componente:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<workflow xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" wfd_version="1.0" reporting="false"
          id="choice" name="choice" descriptor="Componente de elección" startstep="choose"
          xsi:noNamespaceSchemaLocation=".. /.. /.. /configuration/workflow.xsd">
   
    <actions>
        <finish_workflow id="finish_workflow"> 
            <output>
                <param name="selected_button" type="string">#{event:command}</param>
            </output>
        </finish_workflow>
    </actions>
   

    <rules>
        <rule id="menu_button_selection">
            <expression>#{event: comando} == 'MANZANA' || #{event:command} == 'PEAR'</expression>
            <actions>
                <action ref="finish_workflow"/>
            </actions>
        </rule>  
    </rules>

 

    <steps>
        <step id="choose" descriptor="el usuario selecciona entre dos opciones" uitemplate="ChoiceScreen">
            <states>
                <onevent>
                    <rule ref="menu_button_selection"/>
                </onevent>
            </estados>
        </paso><
    /pasos>

</flujo de trabajo>

Descargar componente (posterior a la asignación)

Con esto, has terminado la segunda lección. La siguiente lección tratará sobre las variables de datos.