diff --git a/es_ES/Design_Documentation/appconn/DSS_Access_Scheduling_System-es.md b/es_ES/Design_Documentation/appconn/DSS_Access_Scheduling_System-es.md new file mode 100644 index 0000000..c982483 --- /dev/null +++ b/es_ES/Design_Documentation/appconn/DSS_Access_Scheduling_System-es.md @@ -0,0 +1,81 @@ +# Sistema de programación de acceso DSS + +## fondo + +Hay muchos sistemas de programación de cronometraje por lotes utilizados actualmente en el campo del big data, como Azkaban, Dophinscheduler, Airflow, etc. DataSphere Studio (DSS) admite la publicación de flujos de trabajo diseñados por los usuarios en diferentes sistemas de programación para la programación. Actualmente, el soporte predeterminado para publicar en Azkaban. El usuario ha completado el diseño DAG del flujo de trabajo en DSS, incluida la carga de archivos de recursos de flujo de trabajo, la configuración de parámetros de flujo de trabajo, la importación de datos, la comprobación de calidad de datos, la escritura de código de nodo, el diseño de informes visuales, la salida de correo electrónico, la carga de archivos de recursos de nodo y la configuración de parámetros en ejecución Después de la operación, se puede depurar y ejecutar en DSS. Después de verificar que la ejecución de todos los nodos es correcta, se liberará al sistema de programación, y el sistema de programación programará y ejecutará regularmente de acuerdo con la configuración de la tarea programada. + +### método de lanzamiento + +AppConn debe acceder al nuevo sistema de programación de integración DSS. Los usuarios deben definir el XXXSchedulerAppConn correspondiente de acuerdo con los diferentes sistemas de programación, y la especificación de integración de transformación y la especificación de integración estructurada se definen en SchedulerAppConn. La especificación de integración de transformación contiene la transformación de contenido de nivel de proyecto de DSS y contenido de nivel de flujo de trabajo de DSS a sistemas de programación de terceros. El acceso de DSS al sistema de despacho se puede dividir en los dos tipos siguientes: + +1. Versión a nivel de ingeniería + +Se refiere a convertir todos los flujos de trabajo en el proyecto y empaquetar y cargar uniformemente el contenido convertido en el sistema de programación. Existen principalmente la interfaz ProjectPreConversionRel, que define el flujo de trabajo que debe convertirse en el proyecto. + +2. Versión a nivel de flujo de trabajo + +Se refiere a la conversión de acuerdo con la granularidad del flujo de trabajo, y solo el contenido del flujo de trabajo se empaqueta y se carga en el sistema de programación. La definición actual del flujo de trabajo de DSS se almacena en el archivo BML en forma de Json y la información de metadatos del flujo de trabajo se almacena en la base de datos. + +## Los pasos principales + +### Analizador + +JsonToFlowParser se utiliza para convertir el Json del flujo de trabajo en flujo de trabajo. El flujo de trabajo es el formato estándar para operar el flujo de trabajo en DSS. Incluye la información del nodo del flujo de trabajo, la información de borde del flujo de trabajo, el flujo de trabajo principal, el flujo de trabajo secundario, el archivo de recursos de flujo de trabajo, el archivo de propiedades de flujo de trabajo, el tiempo de creación del flujo de trabajo, el tiempo de actualización, el usuario del flujo de trabajo, el usuario proxy del flujo de trabajo, la información de metadatos del flujo de trabajo como el nombre, el ID, la descripción, el tipo, si se trata de un flujo de trabajo raíz, etc. Estos se analizan de acuerdo con el contenido de Json y se convierten en objetos de flujo de trabajo operables DSS, como AzkabanWorkflow y DolphinSchedulerWorkflow. + +### Convertidor + +Convierta el flujo de trabajo de DSS en un flujo de trabajo que pueda ser reconocido por el sistema de programación de acceso. Cada sistema de programación tiene su propia definición para el flujo de trabajo. Si convierte los nodos del flujo de trabajo de DSS en los archivos de formato de trabajo de Azkaban o en las tareas de DolphinScheduler, también puede convertirlos a la inversa y convertir el flujo de trabajo del sistema de programación en un flujo de trabajo que DSS pueda cargar y mostrar, y las dependencias del flujo de trabajo. , la conexión del nodo se convierte en la dependencia del sistema de programación correspondiente. También puede comprobar si los nodos de flujo de trabajo del proyecto tienen nodos con el mismo nombre en Convertidor. Por ejemplo, el uso de nodos con el mismo nombre no está permitido en el sistema de programación de Azkaban. + +WorkflowConVerter define la estructura de directorios de salida de conversión de flujo de trabajo, incluido el directorio de almacenamiento de flujo de trabajo, el almacenamiento de archivos de recursos de flujo de trabajo y el establecimiento de un directorio de almacenamiento de subflujo de trabajo. Por ejemplo, Azkaban también incluye la creación de un directorio de conversión de proyecto en la operación de conversión de nivel de proyecto y el establecimiento de un directorio de conversión de flujo de trabajo de acuerdo con la situación de flujo de trabajo en el proyecto. Convertir flujo de trabajo a dolphinSchedulerWorkflow o ScheduleWorkFlow en convertToRel + +NodeConverter define el contenido de salida de la conversión de nodos: como ConvertNode de Azkaban, convertirá el contenido del nodo del flujo de trabajo en el contenido del archivo de trabajo correspondiente. Incluyendo el nombre, el tipo, la dependencia del nodo de conversión, el comando de ejecución del nodo (dependiendo del análisis linkis-jobtype), los parámetros de configuración del nodo, la etiqueta del nodo, etc. Finalmente, se almacena en el formato definido por el archivo de trabajo. El convertidor de DolphinScheduler convierte los nodos en DSS en tareas en DolphinScheduler, y crea el script de ejecución de Shell type Task, y convierte el contenido de nodo de DSS en los parámetros necesarios para la ejecución del script de dss-dolphinscheduler-client.sh personalizado. + +```--java + addLine.accept("LINKIS_TYPE", dssNode.getNodeType()); //Workflow Node Type + addLine.accept("PROXY_USER", dssNode.getUserProxy()); //proxy user + addObjectLine.accept("JOB_COMMAND", dssNode.getJobContent()); //Excuting an order + addObjectLine.accept("JOB_PARAMS", dssNode.getParams()); //Node execution parameters + addObjectLine.accept("JOB_RESOURCES", dssNode.getResources()); //Node execution resource file + addObjectLine.accept("JOB_SOURCE", sourceMap); //Node's source information + addLine.accept("CONTEXT_ID", workflow.getContextID()); //context ID + addLine.accept("LINKIS_GATEWAY_URL", Configuration.getGateWayURL()); //linkis gateway address + addLine.accept("RUN_DATE", "${system.biz.date}"); //run date variable +``` + +### Tunning + +Se utiliza para completar la operación de ajuste general antes de que se publique el proyecto. En la implementación de Azkaban, la configuración de ruta del proyecto y la configuración de ruta de almacenamiento del flujo de trabajo se completan principalmente. Debido a que en este momento es posible operar el proyecto = 》flujo de trabajo = 》 sub-flujo de trabajo, es conveniente para configurar la operación de afuera hacia adentro. Por ejemplo, el almacenamiento del flujo de trabajo depende de la ubicación de almacenamiento del proyecto y el almacenamiento del flujo de trabajo secundario depende de la ubicación del flujo de trabajo primario. El cálculo del nodo secundario se completa en FlowTuning y el nodo final se agrega automáticamente. + +## Programación de la implementación de AppConn + +### AbstractSchedulerAppConn + +La clase abstracta de programación AppConn, el nuevo sistema de programación appConn access puede heredar directamente esta clase abstracta, implementa la interfaz SchedulerAppConn y hereda AbstractOnlySSOAppConn, para pasar por el inicio de sesión SSO entre DSS y el sistema de programación. Por ejemplo, dolphins y SchedulisAppConn, ya integrados, heredan esta clase abstracta. + +Esta clase abstracta contiene dos tipos de Estándar + +El primero es ConversionIntegrationStandard para admitir flujos de trabajo que transforman la orquestación DSS en un sistema de programación + +El segundo es SchedulerStructureIntegrationStandard, una especificación de integración estructurada para DSS y sistemas de programación. + +### ConversionIntegrationStandard + +Especificación de integración de conversión para sistemas de programación, incluido DSSToRelConversionService para convertir la orquestación de DSS en flujos de trabajo del sistema de programación. También se reserva una interfaz para admitir la conversión del flujo de trabajo del sistema de programación en la orquestación de DSS + +### AbstractSchedulerStructureIntegrationStandard + +La especificación de integración de la estructura organizativa del sistema de programación se utiliza especialmente para la gestión de la estructura organizativa del sistema de programación, incluidos principalmente los servicios de ingeniería y los servicios de orquestación. + +### ProjectService + +* Se realizan las operaciones unificadas de creación, actualización, eliminación y comprobación duplicada del proyecto. +* Se utiliza para abrir el sistema de ingeniería de la ingeniería DSS y acceder a herramientas de aplicaciones de terceros, y realizar la gestión colaborativa de la ingeniería. +* Si el sistema de programación necesita abrir el sistema de ingeniería con DSS, debe implementar todas las interfaces de los servicios de ingeniería en la especificación de integración estructurada. + +### OrchestrationService + +El servicio de orquestación se utiliza para la especificación de orquestación unificada del sistema de programación y tiene las siguientes funciones: + +* Especificación de orquestación unificada, especialmente utilizada para abrir el sistema de orquestación de DSS y SchedulerAppConn (sistema de programación). +* Por ejemplo: conecte el flujo de trabajo de DSS y el flujo de trabajo de programaciones. +* Tenga en cuenta que si el sistema SchedulerAppConn de acoplamiento no admite el flujo de trabajo de administración en sí, no es necesario implementar esta interfaz. diff --git a/es_ES/Design_Documentation/appconn/DSS_Access_Scheduling_System.md b/es_ES/Design_Documentation/appconn/DSS_Access_Scheduling_System.md new file mode 100644 index 0000000..41a578d --- /dev/null +++ b/es_ES/Design_Documentation/appconn/DSS_Access_Scheduling_System.md @@ -0,0 +1,81 @@ +# DSS access scheduling system + +## background + +There are many batch timing scheduling systems currently used in the field of big data, such as Azkaban, Dophinscheduler, Airflow, etc. DataSphere Studio (DSS) supports publishing workflows designed by users to different scheduling systems for scheduling. Currently, the default support for publishing to Azkaban. The user has completed the DAG design of the workflow in DSS, including workflow resource file loading, workflow parameter setting, data import, data quality check, node code writing, visual report design, email output, node resource file upload and running parameter setting After the operation, it can be debugged and executed in DSS. After verifying that the execution of all nodes is correct, it will be released to the scheduling system, and the scheduling system will schedule and execute regularly according to the configuration of the scheduled task. + +### release method + +The DSS integration new scheduling system needs to be accessed by AppConn. Users need to define the corresponding XXXSchedulerAppConn according to different scheduling systems, and the transformation integration specification and the structured integration specification are defined in the SchedulerAppConn. The transformation integration specification contains the transformation of DSS project-level content and DSS workflow-level content to third-party scheduling systems. The access of DSS to the dispatching system can be divided into the following two types: + +1. Engineering level release + +It refers to converting all the workflows in the project, and uniformly packaging and uploading the converted content to the scheduling system. There are mainly the ProjectPreConversionRel interface, which defines the workflow that needs to be converted in the project. + +2. Workflow level release + +It refers to the conversion according to the granularity of the workflow, and only the content of the workflow is packaged and uploaded to the scheduling system. The current workflow definition of DSS is stored in the BML file in the form of Json, and the metadata information of the workflow is stored in the database. + +## The main steps + +### Parser + +JsonToFlowParser is used to convert the Json of the workflow into Workflow. Workflow is the standard format for operating workflow in DSS. It includes the node information of the workflow, the edge information of the workflow, the parent workflow, the child workflow, the workflow resource file, Workflow property file, workflow creation time, update time, workflow user, workflow proxy user, workflow metadata information such as name, ID, description, type, whether it is a root workflow, etc. These are parsed according to the content of Json and converted into DSS operable Workflow objects, such as AzkabanWorkflow and DolphinSchedulerWorkflow. + +### Converter + +Turn the Workflow of DSS into a workflow that can be recognized by the access scheduling system. Each scheduling system has its own definition for the workflow. If you convert the nodes of the DSS workflow into Azkaban's job format files, or into DolphinScheduler's tasks, you can also convert them in reverse, and convert the workflow of the scheduling system into a workflow that can be loaded and displayed by DSS, and the dependencies of the workflow. , the connection of the node is converted into the dependency of the corresponding scheduling system. You can also check whether the workflow nodes under the project have nodes with the same name in Converter. For example, the use of nodes with the same name is not allowed in Azkaban's scheduling system. + +WorkflowConVerter defines the workflow conversion output directory structure, including workflow storage directory, workflow resource file storage, and establishment of sub-workflow storage directory. For example, Azkaban also includes creating a project conversion directory in the project-level conversion operation, and establishing a workflow conversion directory according to the workflow situation in the project. Convert Workflow to dolphinSchedulerWorkflow or ScheduleWorkFlow in convertToRel + +NodeConverter defines the output content of node conversion: such as Azkaban's ConvertNode, it will convert the node content of the workflow into the corresponding Job file content. Including the name, type, dependency of the conversion node, the execution command of the node (depending on linkis-jobtype parsing), the configuration parameters of the node, the label of the node, etc. Finally, it is stored in the format defined by the Job file. The Converter of DolphinScheduler converts the nodes in DSS into tasks in DolphinScheduler, and builds the execution script of Shell type Task, and converts the node content of DSS into the parameters required for the execution of the custom dss-dolphinscheduler-client.sh script. + +```--java + addLine.accept("LINKIS_TYPE", dssNode.getNodeType()); //Workflow Node Type + addLine.accept("PROXY_USER", dssNode.getUserProxy()); //proxy user + addObjectLine.accept("JOB_COMMAND", dssNode.getJobContent()); //Excuting an order + addObjectLine.accept("JOB_PARAMS", dssNode.getParams()); //Node execution parameters + addObjectLine.accept("JOB_RESOURCES", dssNode.getResources()); //Node execution resource file + addObjectLine.accept("JOB_SOURCE", sourceMap); //Node's source information + addLine.accept("CONTEXT_ID", workflow.getContextID()); //context ID + addLine.accept("LINKIS_GATEWAY_URL", Configuration.getGateWayURL()); //linkis gateway address + addLine.accept("RUN_DATE", "${system.biz.date}"); //run date variable +``` + +### Tunning + +It is used to complete the overall adjustment operation before the project is released. In the implementation of Azkaban, the path setting of the project and the storage path setting of the workflow are mainly completed.Because at this time it is possible to operate the project=》workflow=》sub-workflow，It is convenient for setting operation from outside to inside. For example, the storage of workflow depends on the storage location of the project, and the storage of child workflow depends on the location of the parent workflow. The child node calculation is completed in FlowTuning, and the end node is automatically added. + +## Scheduling the AppConn implementation + +### AbstractSchedulerAppConn + +The abstract class of scheduling AppConn, the new scheduling system AppConn access can directly inherit this abstract class, it implements the SchedulerAppConn interface, and inherits AbstractOnlySSOAppConn, to get through the SSO login between DSS and the scheduling system. For example, the already integrated DolphinSchedulerAppConn and SchedulisAppConn both inherit this abstract class. + +This abstract class contains two types of Standard + +The first is ConversionIntegrationStandard to support workflows that transform DSS orchestration into a scheduling system + +The second is SchedulerStructureIntegrationStandard, a structured integration specification for DSS and scheduling systems + +### ConversionIntegrationStandard + +Conversion integration specification for scheduling systems, including DSSToRelConversionService for converting DSS orchestration into scheduling system workflows. An interface is also reserved to support converting the workflow of the scheduling system into the orchestration of DSS + +### AbstractSchedulerStructureIntegrationStandard + +The scheduling system organizational structure integration specification is specially used for the organizational structure management of the scheduling system, mainly including engineering services and orchestration services. + +### ProjectService + +* The unified creation, update, deletion and duplicate checking operations of the project are realized. +* It is used to open up the engineering system of DSS engineering and access third-party application tools, and realize the collaborative management of engineering. +* If the scheduling system needs to open up the engineering system with DSS, it needs to implement all the interfaces of engineering services in the structured integration specification. + +### OrchestrationService + +The orchestration service is used for the unified orchestration specification of the scheduling system, and has the following functions: + +* Unified orchestration specification, specially used to open up the orchestration system of DSS and SchedulerAppConn (scheduling system). +* For example: connect DSS workflow and Schedules workflow. +* Please note that if the docking SchedulerAppConn system does not support management workflow itself, you do not need to implement this interface. diff --git a/es_ES/Design_Documentation/appconn/appconn-es.md b/es_ES/Design_Documentation/appconn/appconn-es.md new file mode 100644 index 0000000..eaada70 --- /dev/null +++ b/es_ES/Design_Documentation/appconn/appconn-es.md @@ -0,0 +1,30 @@ +## Documentación de diseño de DSS-AppConn + +## Introducir + +    El principio de la AppJoint original es definir una interfaz de nivel superior AppJoint. El tercero implementa esta interfaz y almacena su propia información de conexión en la tabla DSS, e implementa un "servicio proxy" en DSS que se comunica con el sistema de terceros. En la etapa inicial de inicialización, creando una instancia del servicio a través del mecanismo de reflexión, y utilizando la información de conexión en la tabla, DSS puede usar el "servicio proxy" para establecer comunicación HTTP con el sistema de terceros, invocando así el sistema de terceros. Sin embargo, hay deficiencias en el diseño de AppJoint. Cada instancia de aplicación conectada debe generar una instancia de AppJoint. Las diferentes instancias de la misma aplicación no están asociadas lógicamente. La instancia de aplicación AppConn de cada sistema es DSS1.0. La interfaz de nivel superior, en DSS1.0, su propio modo de orquestación, flujo de trabajo, nodo de una sola tarea, etc., son todas instancias de AppConn. Además, los sistemas de terceros que acceden a DSS necesitan implementar la interfaz AppConn para implementar DSS. Integre con sistemas de terceros para llamar a aplicaciones de terceros. Lógicamente, AppConn tiene una lógica de abstracción más alta que AppJoint. AppConn es similar a una instancia de clase, mientras que AppJoint es similar a una instancia. + +### Introducción a los módulos relacionados + +| | del módulo de nivel 1 | del módulo de nivel 2 Introducción a la función| +|-------------|-----------|----------------| +|dss-appconn|appconns| Acceda a DSS para implementar el código de implementación de especificaciones relacionadas con AppConn| +| |dss-appconn-core| Interfaz de Appconn y definición básica de clases| +| |dss-appconn-loader| Creación de instancias, carga y montaje del paquete compilado AppConn de la aplicación conectada| +| |dss-appconn-manager| Interactúe con los módulos del marco y administre la información de instancia de AppConn relacionada| +| |dss-scheduler-appconn| Definición resumida de AppConn para la implementación del sistema de programación| +| |linkis-appconn-engineplugin| Implementar las especificaciones relevantes de linkis appconn y abrir la interacción entre DSS AppConn y Linkis| + +| Interfaz principal/| de clase Funciones principales | +|---------------------------|------------------------------| +| DSSDictionaryRestful、DSSDictionaryServiceImpl | Proporcionar interfaz de adquisición de información de diccionario, consultar registros correspondientes de la tabla de diccionario a través de la clave de parámetro o parentKey | +| DSSWorkspacePrivRestful、DSSWorkspacePrivServiceImpl | Proporciona funciones de visualización y edición para la información de permisos del componente de menú del rol de área de trabajo | +| DSSWorkspaceRestful、DSSWorkspaceServiceImpl | Proporciona interfaces funcionales básicas del espacio de trabajo, como la creación de espacios de trabajo, la obtención de listas de espacios de trabajo, la obtención de información de permisos de componentes de menú, etc. | +| DSSWorkspaceRoleRestful、DSSWorkspaceRoleServiceImpl | Proporciona interfaces de consulta y creación para roles de área de trabajo | +| DSSWorkspaceUserRestful、DSSWorkspaceUserServiceImpl | Proporciona una interfaz para agregar, eliminar, modificar y consultar usuarios del área de trabajo | + +### Diagrama de arquitectura de AppConn + +![](./images/appconn_class_uml.png) +![](./images/appconn_structure.png)\ +![](./images/appconn_load_process.png) diff --git a/es_ES/Design_Documentation/appconn/appconn.md b/es_ES/Design_Documentation/appconn/appconn.md new file mode 100644 index 0000000..b435d94 --- /dev/null +++ b/es_ES/Design_Documentation/appconn/appconn.md @@ -0,0 +1,29 @@ +DSS-AppConn Design Documentation +------ +## Introduce +    The principle of the original AppJoint is to define a top-level interface AppJoint. The third party implements this interface and stores its own connection information in the DSS table, and implements a "proxy service" in DSS that communicates with the third-party system. At the initial stage of initialization , creating an instance of the service through the reflection mechanism, and using the connection information in the table, DSS can use the "proxy service" to establish HTTP communication with the third-party system, thereby invoking the third-party system. However, there are shortcomings in the design of AppJoint. Each connected application instance needs to generate an AppJoint instance. Different instances of the same application are not logically associated. The application instance AppConn of each system is DSS1.0. The top-level interface, in DSS1.0, its own orchestration mode, workflow, single-task node, etc., are all instances of AppConn. In addition, third-party systems that access DSS need to implement the AppConn interface to implement DSS. Integrate with third-party systems to call third-party applications. Logically, AppConn has a higher abstraction logic than AppJoint. AppConn is similar to a class instance, while AppJoint is similar to an instance. + +### Introduction to related modules +|Level 1 Module | Level 2 Module | Function Introduction| +|-------------|-----------|----------------| +|dss-appconn|appconns|Access DSS to implement AppConn related specification implementation code| +| |dss-appconn-core|Appconn interface and basic class definition| +| |dss-appconn-loader|Instantiation, loading and assembly of the AppConn compiled package of the connected application| +| |dss-appconn-manager|Interact with framework modules and manage related AppConn instance information| +| |dss-scheduler-appconn|Abstract AppConn Definition for Scheduling System Implementation| +| |linkis-appconn-engineplugin|Implement the relevant specifications of linkis appconn and open up the interaction between DSS AppConn and Linkis| + + + +| Core interface/class | Core functions | +|---------------------------|------------------------------| +| DSSDictionaryRestful、DSSDictionaryServiceImpl | Provide dictionary information acquisition interface, query corresponding records from dictionary table through parameter key or parentKey | +| DSSWorkspacePrivRestful、DSSWorkspacePrivServiceImpl | Provides viewing and editing functions for the permission information of the menu component of the workspace role | +| DSSWorkspaceRestful、DSSWorkspaceServiceImpl | Provides basic functional interfaces of workspace, such as creating workspace, obtaining workspace list, obtaining permission information of menu components, etc. | +| DSSWorkspaceRoleRestful、DSSWorkspaceRoleServiceImpl | Provides query and creation interfaces for workspace roles | +| DSSWorkspaceUserRestful、DSSWorkspaceUserServiceImpl | Provides an interface for adding, deleting, modifying, and querying workspace users | + +### AppConn Architecture Diagram +![](./images/appconn_class_uml.png) +![](./images/appconn_structure.png) +![](./images/appconn_load_process.png) diff --git a/es_ES/Design_Documentation/appconn/images/appconn_class_uml.png b/es_ES/Design_Documentation/appconn/images/appconn_class_uml.png new file mode 100644 index 0000000..3c6765d Binary files /dev/null and b/es_ES/Design_Documentation/appconn/images/appconn_class_uml.png differ diff --git a/es_ES/Design_Documentation/appconn/images/appconn_load_process.png b/es_ES/Design_Documentation/appconn/images/appconn_load_process.png new file mode 100644 index 0000000..733958d Binary files /dev/null and b/es_ES/Design_Documentation/appconn/images/appconn_load_process.png differ diff --git a/es_ES/Design_Documentation/appconn/images/appconn_structure.png b/es_ES/Design_Documentation/appconn/images/appconn_structure.png new file mode 100644 index 0000000..2287a65 Binary files /dev/null and b/es_ES/Design_Documentation/appconn/images/appconn_structure.png differ