Versiones comparadas

Clave

  • Se ha añadido esta línea.
  • Se ha eliminado esta línea.
  • El formato se ha cambiado.

Transacción Transaction /EDGE/FC_SPRO → Carpetas de configuración "Intérpretes" → "Pasos de intérpretes".

A través de esta configuración se pueden indicar los diferentes pasos del proceso que se quiere desplegar. Se recomienda que se haya hecho previamente un diseño del proceso, tal y como se menciona en el capítulo "Diseñar el proceso de negocio". Igualmente, es requerido que se hayan diseñado los estados tal y como se indica en el capítulo "Diseño de los estados por los que puede pasar el proceso".

Se debe tener claro que el funcionamiento de la ejecución de los pasos se basa en lo siguiente:

  1. Cada vez que se ejecuta el b+ Core Framework, éste verifica las instancias de procesos que aún están en un estado, el cual está marcado como de procesamiento automático.
  2. Toma cada instancia que cumple con el punto uno, y comienza a verificar cada paso desde el primero, según la secuencia.
  3. En la verificación, se valida que el proceso esté en un estado el cual el paso pueda aceptar.
  4. Si se cumple el punto 3, entonces se ejecuta el paso, y al final del mismo pueden resultar dos cosas:
    1. El paso termina satisfactoriamente y se cambia el estado al que está configurado o al que el paso en su implementación indique.
    2. El paso termina con error. Si esto sucede, entonces se termina la ejecución de esta instancia.
  5. Se continúa con el siguiente paso según la secuencia y se vuelve a aplicar la lógica desde el punto 3.

A continuación, se especifican las columnas que se deben diligenciar para crear un paso:

...

SPRO → Configuration Folders "Business Units" → "Business Units steps".

Through this configuration, you can specify the different steps of the process you want to deploy. It is recommended to have previously designed the process, as mentioned in the chapter "Business process design". Additionally, it is required to have designed the states as indicated in the chapter "Design of the states through which the process can pass".

It should be clear that the execution of the steps operates based on the following

  1. Every time the b+ dgtal eInvoice is executed, it checks the process instances that are still in a state marked for automatic processing.
  2. It takes each instance that meets the criteria above and begins to verify each step, starting from the first one according to the sequence.
  3. During the verification process, it validates that the process is in a state that the step can accept.
  4. If the condition in point 3 is met, then the step is executed. At the end of the step, two things may result:
    1. The step completes successfully, and the state is changed to the one configured or as indicated by the step's implementation.
    2. The step encounters an error. If this happens, the execution of this instance is terminated.
  5. The next step in the sequence is continued, and the logic from point 3 is applied again.

Below are the columns that must be filled out to create a step:

  • Step
    Sequential number of the step, indicating the execution sequence of all steps. It is recommended to use increments of 10 to allow for the possibility of adding new steps after the initial ones have been configured.

  • Step name
    Description or name of the step being configured.

  • ABAP Class
    Refers to the ABAP implementation of the step being configured. This ABAP class should implement the interface /EDGE/IF_FC_INTERPRE_STEP.
    Sin embargo, para facilidad de los desarrolladores se ha implementado una clase abstracta que implementa mucha de la lógica que comúnmente se utiliza en un paso, esta clase es However, for developers' convenience, an abstract class that includes much of the commonly used step logic has been implemented. This class is /EDGE/CL_FC_GENERAL_STEP, y ésta implementa la interfaz and it implements the interface /EDGE/IF_FC_INTERPRE_STEP. Por lo tanto, se recomienda que cuando se vaya a crear un paso, se herede de la clase  Therefore, it is recommended that when creating a step, it should inherit from the class /EDGE/CL_FC_GENERAL_STEP. 
    Para más información de los pasos estándar que ya trae el producto, por favor consultar el capítulo "Reutilización de pasos estándar en cualquier proceso". Y para verificar cómo se deben desarrollar los pasos, por favor consultar el capítulo "Desarrollo ABAP de los pasos configurados".
    Estado fin
    Corresponde al estado de finalización exitosa que pueda tener el paso. Si el paso solo puede tener un estado de finalización exitosa, entonces se debe ingresar éste aquí; de lo contrario, si puede tener más de un estado, este campo se debe dejar vacío, y es el paso el que debe determinar el estado de finalización por código (reimplementando o redefiniendo el método GET_FINAL_STATUS). Si por el contrario, el paso no modifica el estado en el cual viene el proceso, también se debe dejar vacío y no se debe implementar la determinación del mismo en el paso, ya que en el paso genérico 
    For more information on the standard steps included in the product, please refer to the chapter "Reuse of Standard Steps in any Process". To understand how steps should be developed, please consult the chapter "ABAP Development of Configured Steps".


  • Final Stat
    Represents the successful completion state that the step can reach. If the step can only have one successful completion state, it should be entered here. Otherwise, if it can have multiple states, this field should be left empty, and it should be the step's responsibility to determine the final state programmatically (by reimplementing or redefining the GET_FINAL_STATUS method). If, on the other hand, the step does not modify the current state of the process, this field should also be left empty, and the determination of the final state should not be implemented in the step. The generic step /EDGE/CL_FC_GENERAL_STEP
    , se tiene en cuenta que si no se ha ingresado estado fin y no se reimplementó o se redefinió el método GETtakes this into account; if no final state is entered and the GET_FINAL_STATUS , el estado no se cambiará.
    Estado err
    Corresponde al estado de finalización errónea que pueda tener el paso. Si el paso solo puede tener un estado de finalización errónea, entonces se debe ingresar éste aquí; de lo contrario, si puede tener más de un estado, este campo se debe dejar vacío, y es el paso el que debe determinar el estado de finalización por código (reimplementando o redefiniendo el método GET_FINAL_STATUS). Si por el contrario, el paso no es susceptible de lanzar excepciones debido a que es muy simple su ejecución, también se debe dejar vacío y no se debe implementar la determinación del mismo en el paso, ya que en el paso genérico method is not reimplemented or redefined, the state will not change.

  • State err
    Represents the error completion state that the step can reach. If the step can only have one error completion state, it should be entered here. Otherwise, if it can have multiple states, this field should be left empty, and it should be the step's responsibility to determine the error state programmatically (by reimplementing or redefining the GET_FINAL_STATUS method). If, on the other hand, the step is not susceptible to throwing exceptions because its execution is straightforward, this field should also be left empty, and the determination of the error state should not be implemented in the step. The generic step /EDGE/CL_FC_GENERAL_STEP
    , se tiene en cuenta que si no se ha ingresado estado fin y no se reimplementó o se redefinió el método GETtakes this into account; if no error state is entered and the GET_FINAL_STATUS , el estado no se cambiará.

Ejemplo de la configuración:

...

  • method is not reimplemented or redefined, the state will not change.

Example of the configuration:

Image Added