DBiLeSi commented on issue #8105:
URL: https://github.com/apache/hop/issues/8105#issuecomment-5435639396

   Thank you for the quick reply. Maybe let me clarify this a little. I think I 
want two separate things.
   
   The first is the description of the workflow, which is executed as an 
asynchronous workflow on the server. The scenario here is: I notice that an 
execution did not go through as planned and can quickly see in the Server UI 
which workflow it was, along with some information about the workflow that I 
included in the description. This would help me identify the workflow causing 
the problem more quickly and hopefully provide the context I need to fix it.
   
   The second scenario is the following: I have a HOP Server running with many 
asynchronous workflows. These workflows are triggered by a separate scheduling 
process, such as Rundeck or Airflow. The challenge is that, in the external 
scheduler, I would like to have a description of what each workflow does.
   
   I can maintain this information by hand, but then I have to maintain two 
descriptions: one in HOP for the developers and one in the scheduler for the 
people who sometimes trigger the workflows manually or want to know what the 
workflows do. For example, which files are ingested and from where, or in which 
database table the final result is saved.
   
   My idea is that, if the asynchronous workflow could expose the description 
of the underlying HOP workflow, this description could be used in the 
scheduler. This would mean that developers only need to maintain one 
description or piece of documentation, which could then be synchronized 
periodically between the HOP Server and the scheduler.
   
   This would give us a single source of truth for the workflow documentation, 
located directly in the workflows themselves. I understand that the execution 
is stateless, but I am not interested in the execution. I am more interested in 
information about the underlying workflow, such as its description, extended 
description, and path.
   
   The latter scenario is the more interesting one for me.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to