Implementation method of configurable financial multi-platform work task public component

Abstract

The application discloses an implementation method of a configuration-based financial multi-platform work task public component. The method comprises the following steps: determining a binding relationship between a specific platform party and a work task configuration and storing the binding relationship; a service end builds a multi-platform work task public component according to platform task setting, platform task scheduling, platform task running and platform task results, the multi-platform work task public component exposes an API interface and calls the API interface after SSL encryption, and the multi-platform work task public component obtains a business processing result by calling an interface exposed by a business system; and finally, the business processing result and the task result are interacted with the platform party through an API or a file service. The application solves the problem of function redundancy of the system, improves the scalability and isolation of the system, and is easy to maintain and upgrade; the differences in scheduling, running and result interaction of different platforms and different works are realized, and the absolute safety of business activities is ensured.

Description

Technical Field

[0001] This invention relates to the technical field of implementation methods for common components of configurable financial multi-platform work tasks, and specifically to implementation methods for common components of configurable financial multi-platform work tasks. Background Technology

[0002] In recent years, with the continuous development and expansion of our industry's business scale, more and more business support systems have emerged. As a banking and financial system, business complementarity with platform providers is an essential business requirement. Therefore, in order to cooperate with the platform providers and the task management of cross-application systems within the bank, various work tasks are usually built to support business development, resulting in various platform work tasks being scattered across various application systems.

[0003] The platform providers that the various application systems are connected to are not transparent within the bank. If a platform provider requests adjustments to business logic, all application systems need to be checked, which is not conducive to management and is also very easy to cause omissions.

[0004] Secondly, the platform tasks of each system are built upon the application's own architecture, resulting in a complex and diverse implementation of these tasks. Specifically, the same tasks are repeatedly implemented across different application systems, leading to extremely redundant code. This complex architecture creates significant difficulties for code expansion and maintenance; the practice of reinventing the wheel, by simply stacking functions, also results in redundancy.

[0005] By analyzing the platform work tasks of the banking and financial industries and drawing on the ideas of BPMN, a task template approach is used to standardize complex and diverse work tasks. Similar tasks are categorized and unified, while different tasks are customized. This encapsulates complex business processes and makes it possible to integrate and modularize platform work tasks based on the categorization of tasks. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by providing a method for implementing a common component for multi-platform work tasks in the financial sector.

[0007] To achieve the above objectives, this invention provides a method for implementing a common component for configurable financial multi-platform work tasks, including:

[0008] Step 1: Determine and store the binding relationship between the specific platform provider and the work task configuration;

[0009] Step 2: The server builds a multi-platform work task common component based on the platform task settings, platform task scheduling, platform task execution, and platform task results. The multi-platform work task common component exposes API interfaces and is encrypted with SSL for the platform to call.

[0010] Step 3: The multi-platform task public component obtains the application business processing result by calling the application business service interface. After the task is completed, it queries the task result from the database according to the task serial number, generates a result file based on the business processing result and the task result, and synchronizes the result file to the platform in a set synchronization method.

[0011] Furthermore, step 1 specifically includes:

[0012] Step 1.1: Use basic platform information to identify the platform provider;

[0013] Step 1.2: Define a task type for each specific task to identify that specific work task;

[0014] Step 1.3: Define a business code for each specific business scenario to identify that specific business;

[0015] Step 1.4: Determine the specific work task using the platform's basic information, task type, and business code;

[0016] Step 1.5: Divide the work task template into two parts: process template number and process template parameter list. The process template number is unique, and the process template parameter list is used to fill in the work task template to generate the final work task details.

[0017] Step 1.6: Bind and store the specific work tasks in Step 1.4 with the work task templates in Step 1.5.

[0018] Furthermore, the platform's basic information includes the platform ID, merchant ID, and customer type.

[0019] Furthermore, the platform's invocation method in step 2 is as follows:

[0020] The platform queries the platform's task configuration through the API interface of the multi-platform task public component. Based on the platform's basic information, task type, and business code, it determines the scheduling method and scheduling time for the specific task of the platform. The platform number, merchant number, customer type, task type, business code, and process parameter list are used as request parameters to generate scheduling request information.

[0021] After receiving the scheduling request information, the multi-platform task public component queries the database for the configured process template parameter list based on the value of the bound task template number to verify whether the parameter sub-items in the process parameter list in the scheduling request information HTTPS sent by the platform are complete. If complete, a workflow instance is generated and a task serial number is generated. Then, the platform number information, the task serial number, and all request parameters are stored in the database.

[0022] The workflow engine uses the task serial number to find the corresponding platform task, thereby driving the task details to be executed step by step.

[0023] Furthermore, the workflow engine is the open-source component Activiti7 based on BPMN 2.0.

[0024] Furthermore, the scheduling method includes internal calls and external calls. If it is an internal call, the platform does not have the authority to schedule tasks, and the scheduling entry point is controlled by the multi-platform task common component itself. If it is an external call, the scheduling entry point is handed over to the platform, and the multi-platform task common component does not control it.

[0025] Furthermore, the synchronization methods include API interface synchronization and file interface synchronization. If it is API interface synchronization, the result file will be notified to the platform through the callback method in the request parameter list provided by the platform. If it is file interface synchronization, the file will be moved through the file path in the request parameter list provided by the platform, and the result file will be given to the platform.

[0026] Beneficial effects: 1. This invention separates the platform tasks that various application systems access for business needs from the original application systems, forming independent public component services. This solves the problem of complex and diverse platform task implementations on different architectures. Simultaneously, the components isolate the task functions from specific application systems, improving system scalability and isolation. Independent public components facilitate bank maintenance of all connected platforms, providing a comprehensive overview of all platform task information. The maintenance and iteration of independent public components also become much easier. Application systems do not need frequent iterations due to platform business adjustments; only component iterations are required to adapt to various business needs of different platforms.

[0027] 2. In specific fields such as banking, platform tasks are divided into two types: scheduled and polling tasks. Scheduling types are divided into internal and external calls. Complex task details are encapsulated through task templates, and task execution is driven by the task engine. Binding specific platform components to task configurations makes multi-platform task functionality modularization possible. This allows for the use of common components across multiple platforms through simple configuration, while also differentiating task results in different scenarios based on the input parameters.

[0028] 3. This invention uses an SSL-based encryption mechanism, requiring the platform to authenticate with an SSL certificate before requesting genuine business activities, thus ensuring the absolute security of business activities. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the workflow of the common component for multi-platform work tasks in an embodiment of the present invention. Detailed Implementation

[0030] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. These embodiments are implemented based on the technical solutions of the present invention, and it should be understood that these embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention.

[0031] like Figure 1 As shown, this embodiment of the invention provides a method for implementing a common component for configurable financial multi-platform work tasks, including:

[0032] Step 1: Determine and store the binding relationship between the specific platform provider and the work task configuration.

[0033] Since the specific platform (such as Suning Finance's product synchronization task) will definitely occur on a certain task template, it can be achieved through the following steps:

[0034] Step 1.1: Identify the platform provider using basic platform information. This basic platform information is preferably the platform ID (platCode), merchant ID (merchantCode), and customer type (custType).

[0035] Step 1.2: Define a task type (taskType) for each specific task to identify that specific work task.

[0036] Step 1.3: Define a business code (bizCode) for each specific business scenario to identify that specific business.

[0037] Step 1.4: Determine the specific work task by using the above platform basic information (platform ID platCode, merchant ID merchantCode, customer type custType) + task type (taskType) + business code (bizCode).

[0038] For example:

[0039] {

[0040] platinumCode:SNYD0001, / / SNYD0001 represents Suning Finance

[0041] merchantCode:SNYD0001, / / SNYD0001 represents Suning Finance

[0042] custType:01, / / 01 - represents individual clients, 02 - represents corporate clients

[0043] taskType: 1 / / 1- represents scheduled execution, 2- represents polling execution

[0044] bizCode:200, / / 200 represents product synchronization

[0045] }

[0046] This represents a complete business activity: A platform is applying to execute a product synchronization task, and the component server receives the task application.

[0047] Step 1.5: Divide the work task template into two parts: process template number (taskTemplateCode) and process template parameter list (taskTemplateParams). The process template number is unique, and the process template parameter list is used to populate the work task template to generate the final work task details and other content.

[0048] For example, suppose there is a workflow template for "Suning Finance Synchronous Product Work Tasks":

[0049] Suning Financial synchronizes product work tasks

[0050] Process begins

[0051] Wealth Management Department Approval

[0052] Finance Department Approval

[0053] Risk Management Department Approval

[0054] Notify an application system (variables: appCode) to generate a product information file (variables: fileName) of a certain type (variables: prodType) in a certain directory (variables: appFilePath).

[0055] Migrate the file (variables: fileName) to a specified directory on the platform (variables: platFilePath).

[0056] Process ended

[0057] Then the task template has a unique taskTemplateCode to represent it, and the parameters variables in the template are composed of taskTemplateParams mapping and matching.

[0058] Step 1.6: Bind and store the specific platform-side task from Step 1.4 with the work task template from Step 1.5. The storage location can be a database such as MySQL.

[0059] A platform task is uniquely identified by a combination of platform ID (platCode), merchant ID (merchantCode), customer type (custType), task type (taskType), business code (bizCode), and process template number (taskTemplateCode).

[0060] Step 2: The server builds a multi-platform task public component based on platform task settings, scheduling, execution, and results. This component exposes API interfaces, which are then encrypted with SSL for platform access. SSL encryption protects sensitive data during transmission; business activities are only executed if the SSL certificate is authenticated, otherwise an error is returned. This enhances security because, without SSL encryption, hackers can use simulated HTTP requests to directly request platform tasks that shouldn't be scheduled. The task design and execution are driven by a task engine, which includes the open-source Activiti7 component based on BPMN 2.0. Specific application systems do not need to concern themselves with the task flow design, workflow, or other logic. The platform access method is as follows:

[0061] The platform queries the platform's task configuration through the API interface of the multi-platform task public component. Based on the platform's basic information, task type, and business code, it determines the scheduling method and time for the specific task. It then generates a scheduling request message (HTTPS) using the platform ID (platCode), merchant ID (merchantCode), customer type (custType), task type (taskType), business code (bizCode), and process parameter list (taskParams) as request parameters. This HTTPS scheduling request message is then sent via SSL encryption. The scheduling methods include internal and external calls. For internal calls, the platform does not have the authority to schedule tasks, and the scheduling entry point is controlled by the multi-platform task public component itself. For external calls, the scheduling entry point is handled by the platform, and the multi-platform task public component does not control it. However, if a call time is set, scheduling outside the set time will be rejected by the multi-platform task public component.

[0062] After receiving the scheduling request information, the multi-platform task common component uniquely identifies a process template number (taskTemplateCode) bound to it based on the platform number (platCode), merchant number (merchantCode), customer type (custType), task type (taskType), and business code (bizCode). It then queries the database for the configured process template parameter list (taskTemplateParams) based on the bound task template number (taskTemplateCode) to verify whether the parameter sub-items in the process parameter list (taskParams) in the scheduling request information (HTTPS) sent by the platform are complete. If complete, a workflow instance is generated, along with a task serial number. The platform number, task serial number, and all request parameters are then stored in the database. Generating a workflow instance essentially generates the detailed work task content.

[0063] The workflow engine locates the corresponding platform task based on the task serial number to drive the step-by-step execution of the task details. Specifically, the multi-platform task common component starts the Activiti workflow engine via ProcessEngineq, loads the task workflow resource (e.g., bpmn / syncProdInfo.bpmn) corresponding to the workflow template number (taskTemplateCode) through the RepositoryService, deploys the workflow definition using DeploymentBuilder, instantiates the task workflow details, and initializes the task detail tables as: sys_clear_task_exec (task master information: taskId, taskName, workDate, taskStatus, etc.) and sys_clear_task_sub_exec (task sub-step information: taskId, stepNo, stepName, startTime, endTime, subExecStatus). After the task component completes the task detail initialization, the management of each task sub-step is implemented through TaskService, including task querying, task rerunning, task skipping, task completion, etc.

[0064] Step 3: The multi-platform task public component obtains the application business processing results by calling the application business service interface. After the task is completed, it queries the task results from the database according to the task serial number, generates a result file based on the business processing results and the task results, and synchronizes the result file to the platform in a set synchronization method.

[0065] The above synchronization methods include API interface synchronization and file interface synchronization. If it is API interface synchronization, the result file will be sent to the platform via the callback method in the request parameter list provided by the platform. If it is file interface synchronization, the file will be moved via the file path in the request parameter list provided by the platform, and the result file will be sent to the platform.

[0066] In summary, the multi-platform task public component of this embodiment is deployed on the public platform server. During operation, the platform sends an SSL-encrypted scheduling request (HTTPS) through the component API interface, requesting the multi-platform task public component to execute the requested task. The multi-platform task public component finds the task template to be executed based on the binding relationship between the platform's request parameters and the task template. After satisfying the process request parameter list verification, it initializes and generates task details based on the task template, obtains business result information by calling the application system's business service interface, and finally returns the business result information and task result information to the platform.

[0067] The above description is merely a preferred embodiment of the present invention. It should be noted that for those skilled in the art, other parts not specifically described are existing technology or common knowledge. Several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for implementing a configuration-based multi-platform public component for financial tasks, characterized in that: include: Step 1: Determine and store the binding relationship between the specific platform provider and the work task configuration; Step 2: The server builds a multi-platform work task common component based on the platform task settings, platform task scheduling, platform task execution, and platform task results. The multi-platform work task common component exposes API interfaces and is encrypted with SSL for the platform to call. Step 3: The multi-platform task public component obtains the application business processing result by calling the application business service interface. After the task is completed, it queries the task result from the database according to the task serial number, generates a result file according to the business processing result and the task result, and synchronizes the result file to the platform in a set synchronization method. Step 1 specifically includes: Step 1.1: Use basic platform information to identify the platform provider; Step 1.2: Define a task type for each specific task to identify the specific work task; Step 1.3: Define a business code for each specific business scenario to identify the specific business; Step 1.4: Determine the specific work task based on the platform's basic information, task type, and business code; Step 1.5: Divide the work task template into two parts: process template number and process template parameter list. The process template number is unique, and the process template parameter list is used to fill in the work task template to generate the final work task details. Step 1.6: Bind and store the specific work tasks from Step 1.4 with the work task templates from Step 1.5; Basic platform information includes platform ID, merchant ID, and customer type; The platform calls the method described in step 2 as follows: The platform queries the platform's task configuration through the API interface of the multi-platform task public component. Based on the platform's basic information, task type, and business code, it determines the scheduling method and scheduling time for the specific task of the platform. The platform number, merchant number, customer type, task type, business code, and process parameter list are used as request parameters to generate scheduling request information. After receiving the scheduling request information, the multi-platform task public component queries the database for the configured process template parameter list based on the value of the bound process template number to verify whether the parameter sub-items in the process parameter list in the scheduling request information sent by the platform are complete. If complete, a workflow instance is generated and a task serial number is generated. Then, the platform number, task serial number and all request parameters are stored in the database. The workflow engine uses the task serial number to find the corresponding platform task, thereby driving the task details to be executed step by step.

2. The implementation method of the common component for configurable financial multi-platform work tasks according to claim 1, characterized in that, The workflow engine is Activiti7, an open-source component based on BPMN 2.

0.

3. The implementation method of the common component for configurable financial multi-platform work tasks according to claim 1, characterized in that, The scheduling methods include internal calls and external calls. If it is an internal call, the platform does not have the authority to schedule tasks, and the scheduling entry point is controlled by the multi-platform task common component itself. If it is an external call, the scheduling entry point is handed over to the platform, and the multi-platform task common component does not control it.

4. The implementation method of the common component for configurable financial multi-platform work tasks according to claim 1, characterized in that, Synchronization methods include API interface synchronization and file interface synchronization. If it is API interface synchronization, the result file will be notified to the platform through the callback method in the request parameter list provided by the platform. If it is a file interface synchronization, the file will be moved according to the file path in the request parameter list provided by the platform, and the result file will be given to the platform.

Images