CN117118993A

CN117118993A - Service intercommunication method and device and electronic equipment

Info

Publication number: CN117118993A
Application number: CN202311069428.7A
Authority: CN
Inventors: 余海军; 梅卫
Original assignee: Beijing Hesi Information Technology Co Ltd
Current assignee: Beijing Hesi Information Technology Co Ltd
Priority date: 2023-08-23
Filing date: 2023-08-23
Publication date: 2023-11-24

Abstract

The invention provides a service intercommunication method, a device and electronic equipment, comprising the following steps: synchronizing a service to be communicated of a first service communication end, wherein the first service communication end comprises: a micro-OA system or an easy-to-report financial reimbursement system; synchronizing the service to be communicated to a second service communicating end, wherein the second service communicating end comprises: the universal micro OA system or the quick-reporting financial reimbursement system, and the second business interconnection end is different from the first business interconnection end. In the service intercommunication method, the service scene of the high-frequency use of the micro-OA system and the quick-reporting financial reimbursement system is subjected to data intercommunication and service interconnection through the middleware service, so that the service intercommunication of the micro-OA system and the quick-reporting financial reimbursement system can be realized.

Description

Service intercommunication method and device and electronic equipment

Technical Field

The present invention relates to the field of software technologies, and in particular, to a method, an apparatus, and an electronic device for service interworking.

Background

In the daily management process, enterprises can use a three-party OA system, wherein the market occupation ratio of the micro-OA system is high, and meanwhile, the enterprises can use a three-party financial reimbursement system, wherein the three-party financial reimbursement system is selected and used for most purposes.

In an actual service usage scenario, service interworking between two systems often exists, for example, the organization architecture information of the micro-OA system is synchronized to the easy-to-report financial reimbursement system, the address book of the micro-OA system is synchronized to the easy-to-report financial reimbursement system (including departments and personnel), the micro-OA system is single-point logged on to the easy-to-report financial reimbursement system, the message to be handled by the easy-to-report financial reimbursement system is synchronized to the micro-OA system, the business trip application form of the easy-to-report financial reimbursement system is synchronized to the micro-OA system, and the projects of the micro-OA system are synchronized to the easy-to-report financial reimbursement system. How to realize business intercommunication between the micro-OA system and the easy-to-report financial reimbursement system becomes a technical problem to be solved in the present technology.

To sum up, the prior art cannot realize the business intercommunication between the micro-OA system and the easy-to-report financial reimbursement system.

Disclosure of Invention

In view of the above, the present invention aims to provide a service interworking method, device and electronic equipment, so as to alleviate the technical problem that the service interworking of the micro-OA system and the quick-reporting financial reimbursement system cannot be realized in the prior art.

In a first aspect, an embodiment of the present invention provides a method for service interworking, which is applied to a middleware service, where the method includes:

Synchronizing a service to be communicated of a first service communication end, wherein the first service communication end comprises: a micro-OA system or an easy-to-report financial reimbursement system;

synchronizing the service to be communicated to a second service communicating end, wherein the second service communicating end comprises: the generic micro OA system or the easy-to-report financial reimbursement system, and the second service interconnection end is different from the first service interconnection end.

In the embodiment of the invention, a service intercommunication method is provided, which is applied to middleware services and comprises the following steps: synchronizing a service to be communicated of a first service communication end, wherein the first service communication end comprises: a micro-OA system or an easy-to-report financial reimbursement system; synchronizing the service to be communicated to a second service communicating end, wherein the second service communicating end comprises: the universal micro OA system or the quick-reporting financial reimbursement system, and the second business interconnection end is different from the first business interconnection end. According to the method for service intercommunication, disclosed by the invention, the service scene of high-frequency use of the micro-OA system and the quick-reporting financial reimbursement system is subjected to data intercommunication and service interconnection through the middleware service, so that the service intercommunication of the micro-OA system and the quick-reporting financial reimbursement system can be realized, and the technical problem that the service intercommunication of the micro-OA system and the quick-reporting financial reimbursement system cannot be realized in the prior art is solved.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are needed in the description of the embodiments or the prior art will be briefly described, and it is obvious that the drawings in the description below are some embodiments of the present invention, and other drawings can be obtained according to the drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of a method for service interworking provided by an embodiment of the present invention;

fig. 2 is a schematic diagram of a device for service interworking according to an embodiment of the present invention;

fig. 3 is a schematic diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

The technical solutions of the present invention will be clearly and completely described in connection with the embodiments, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

The prior art cannot realize service intercommunication between the micro OA system and the easy-to-report financial reimbursement system.

Based on the above, in the service intercommunication method, the service scene of high-frequency use of the micro-OA system and the quick-reporting financial reimbursement system is subjected to data intercommunication and service interconnection through the middleware service, so that the service intercommunication of the micro-OA system and the quick-reporting financial reimbursement system can be realized.

For the convenience of understanding the present embodiment, a method for service interworking disclosed in the present embodiment will be described in detail.

Embodiment one:

according to an embodiment of the present invention, there is provided an embodiment of a method of business interworking, it being noted that the steps shown in the flowcharts of the figures may be performed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowcharts, in some cases the steps shown or described may be performed in an order different from that herein.

Fig. 1 is a flowchart of a method of service interworking according to an embodiment of the present invention, as shown in fig. 1, the method comprising the steps of:

step S102, synchronizing the service to be communicated of a first service communication end, wherein the first service communication end comprises: a micro-OA system or an easy-to-report financial reimbursement system;

Step S104, synchronizing the service to be communicated to a second service communicating end, wherein the second service communicating end comprises: the universal micro OA system or the quick-reporting financial reimbursement system, and the second business interconnection end is different from the first business interconnection end.

The foregoing briefly describes the method of service interworking of the present invention, and the detailed description of the specific details involved therein follows.

In the invention, before service intercommunication, a data model is required to be established, wherein the data model comprises the following steps:

table name: t_if_part;

remarks: for local department data.

Table name: t_if_bill

Remarks: for storing vendor invoices.

Table name: t_if_staffs

Remarks: a personnel data interface.

Table name: t_if_bill_Aptive_states

Remarks: and after analyzing the document state, sending the message according to the approval state.

Table name: t_if_acquisition

Remarks: for storing the application form.

Table name: t_if_project

Remarks are for storing items.

Table name: t_if_ sdk _entitys

Remarks: for storing business object information.

In an optional embodiment of the present invention, when the service to be intercommunicated is a department service, the first service interconnection end is a generic micro OA system, and the second service interconnection end is an easy-to-report financial reimbursement system, (11) synchronizing the service to be intercommunicated of the first service interconnection end includes:

(111) Calling a department interface provided by the universal micro OA system to acquire all departments;

(112) Detecting whether a current department exists according to the department ID of the current department provided by the micro-OA system;

(113) Determining an execution action according to the detection result, and executing the execution action, wherein when the detection result is nonexistent, the corresponding execution action is newly added, and when the detection result is present and needs to be updated, the corresponding execution action is updated;

(114) Traversing each currently stored target department, searching department IDs corresponding to the target departments in the micro-OA system to judge whether the target departments are in a department list returned by the micro-OA system;

(115) If the corresponding execution action is not in the department list returned by the micro-OA system, determining that the execution action corresponding to the target department is deletion;

specifically, the sync department is local to the middleware:

and starting a department synchronization timing task, reading a department information interface provided by the OA, acquiring all department information, and synchronizing data to the middle table according to the department state. The specific implementation flow is as follows:

1. and calling a department interface provided by the universal micro OA system to acquire all departments.

2. Detecting whether the department exists locally according to the general micro department ID, if not, adding the department, and setting action as CREATE. If so, detecting whether the UPDATE is needed, and if so, setting the action as UPDATE.

The generic micro OA acquisition all departments interface as follows:

https:// oa. Qkmtech. Com/services/HrmService (wsdl link address)

3. Reversely checking whether the local department data is in a department list returned by the micro-OA;

traversing the local department data, checking whether the micro-OA department ID is in the department list data returned by the micro-OA for each piece of data, and if so, indicating that the department is not deleted; if not, the description department has been deleted, at which point the action in the local department table is set to DELETE.

To this end, the department synchronizes to the local logic completion.

(12) Synchronizing the service to be interworking to a second service interworking end, comprising:

(121) Determining an execution action in the currently stored departments as a target department for new addition or update or deletion;

(122) If the execution action of the first target department is newly added, judging whether an easy-to-report ID corresponding to the first target department exists or not;

(123) If the easy-to-report ID does not exist, checking whether the first target department exists in the easy-to-report financial reimbursement system;

(124) If the first target department does not exist in the quick report financial reimbursement system, the first target department is newly added in the quick report financial reimbursement system;

(125) If the first target department exists in the quick report financial reimbursement system, modifying the information of the first target department in the quick report financial reimbursement system;

(126) If the execution action of the second target department is updated, modifying the information of the second target department in the quick report financial reimbursement system;

(127) And if the execution action of the third target department is deletion, disabling the third target department in the quick-report financial reimbursement system.

Specifically, synchronizing the local department to an easy-to-report address book;

1. acquiring departments with the CREATE and UPDATE states in a local department information table;

2. and assembling department data.

If the department=create, it is first determined whether there is a department corresponding easy-to-report id in the local department interface table, if not, then the easy-to-report is called to "get department information interface according to the department id or code", and it is checked whether the department already exists in the easy-to-report.

Acquiring department information interface description address according to department id or code: https:// www.ekuaibao.com/help/openapi/contacts/get-parts-idOrCode.ht ml;

if the department does not exist in the quick report, calling a new interface of the department to newly add department data;

the newly added department interface illustrates the address: https:// www.ekuaibao.com/help/openapi/contacts/add-parts.

And if the department exists in the quick report, calling a quick report modification department interface to modify department information.

Modifying department information interface description address: https:// www.ekuaibao.com/help/openapi/contacts/update-parts.

If action=update, the easy-to-report modification department interface is invoked to modify the department information.

If action=delete, then invoke the easy quick stop enable department interface, stop the department information.

Disabling department information interface description address: https:// www.ekuaibao.com/help/openapi/contacts/active-parts.

So far, the local department is synchronized to the logic completion of the address book easy to report.

In an optional embodiment of the present invention, when the service to be intercommunicated is employee data, the first service interconnection end is a generic micro OA system, and the second service interconnection end is an easy-to-report financial reimbursement system, (21) synchronizing the service to be intercommunicated of the first service interconnection end includes:

(211) Invoking an employee data interface provided by the micro-OA system to acquire all employee data;

(212) Detecting whether current employee data exist according to the employee ID of the current employee data provided by the micro OA system;

(213) Determining an execution action according to the detection result, and further executing the execution action, wherein when the detection result is nonexistent, the corresponding execution action is newly added, when the detection result is existing and needs to be updated, the corresponding execution action is updated, and when the detection result is that the current employee data display the corresponding current employee to be away, the corresponding execution action is deleted;

Specifically, OA employee data synchronization local temporary table:

and starting an employee synchronization timing task, reading an employee information interface provided by the OA, acquiring all employee information, and synchronizing data to an intermediate table according to the employee state. The specific implementation flow is as follows:

1. the middleware reads all employee data in the interface according to the interface provided by the oa, and judges whether the employee data are in a local comparison table according to the employee id (or the work number);

2. if the employee data does not exist, the employee data is newly added to the local area, and meanwhile, the department to which the employee belongs is set; when newly added, the ACTION is: newly adding;

3. if the staff code exists, judging whether the staff needs to be modified according to the staff code, the name of the staff, the mobile phone number, the mailbox, the department ID of the staff, and the like; if the local data needs to be modified, updating the local data; namely setting the ACTION as modification;

4. judging whether the staff leaves the staff according to the staff state; if the job is left, the ACTION in the local employee record table is modified as follows: and deleting.

(22) Synchronizing the service to be interworking to a second service interworking end, comprising:

(221) If the execution action of the first target employee data is newly increased, acquiring a first quick report department ID in corresponding department information according to a department to which the employee in the first target employee data belongs, and further newly increasing the first target employee data in a department corresponding to the first quick report department ID;

(222) If the execution action of the second target employee data is update, acquiring a second quick report department ID in corresponding department information according to a department to which the employee in the second target employee data belongs, and updating the second target employee data in a department corresponding to the second quick report department ID;

(223) If the execution action of the third target employee data is deletion, disabling the third target employee data on the quick-report financial reimbursement system;

(224) And modifying the execution actions of the first target employee data, the second target employee data and the third target employee data to be none.

Specifically, employee data is synchronized to easy flash report:

the middleware synchronizes the local employee data to the easily quick-report address book employee. The specific implementation flow is as follows:

1. middleware is started to read employee data to be synchronized locally;

2. if action=create, it is explained that the employee needs to be newly added, and the easy-to-report department ID in the department information is obtained according to the department to which the employee belongs. And calling an easy-to-report newly-added employee interface to perform newly-added operation on the employee.

Easily and quickly reporting the interface description address of the newly added employee:

https://www.ekuaibao.com/help/openapi/contacts/add-staffs.html；

3. if action=update, then the employee information is described as needing to be updated; at this time, according to the employee department information recorded in the local table, a new easy-to-report department ID corresponding to the employee needing to be modified is obtained. Acquiring department information interface description address according to codes:

https://www.ekuaibao.com/help/openapi/contacts/get-departments-idOrCod e.html；

After the new department information of the employee is acquired, the employee department attribute is set. And calling an easy-to-report employee information modifying interface to modify employee information.

Quick report modification employee information interface description address:

https://www.ekuaibao.com/help/openapi/contacts/update-staffs.html；

4. if action=delayed, then the employee information on the quick report needs to be disabled. And directly calling an easy-to-report employee information interface to stop the employee.

Easy quick report disabling employee interface description address:

https://www.ekuaibao.com/help/openapi/contacts/active-staffs.html；

5. after the employee information synchronization is completed, modifying an Action field in the local record table to be: none, i.e., indicating that employee information has been processed, does not require a timed task to be processed again.

In an optional embodiment of the present invention, when the service to be interworking is a single sign-on service, the first service interworking end is a generic micro OA system, and the second service interworking end is an easy-to-report financial reimbursement system, (31) synchronizing the service to be interworking of the first service interworking end includes:

(311) Acquiring a work number of the staff single sign-on sent by the micro-OA system, wherein a single sign-on entrance is configured in the micro-OA system, and the staff inputs the work number at the single sign-on entrance;

(32) Synchronizing the service to be interworking to a second service interworking end, comprising:

(321) Determining a corresponding employee ID easy to report according to the work number, and calling an easy to report temporary authorization interface to perform single sign-on authorization so as to acquire a temporary authorization page;

(322) And analyzing the temporary authorization page and redirecting the employee page to the temporary authorization page.

Specifically, 1. Start: in the micro OA, an entry for single sign-on is configured. The entry may be a menu or an icon; in particular according to the customer requirements.

Middleware login entry address:

http://ip:port/single/logincode＝*****

wherein, the code represents the work number of the login user after the current login user is in the micro login.

2. Inquiring local table data according to the work number transmitted by the OA, acquiring the quick report employee id stored in the local table, if the quick report employee id exists, calling a quick report temporary authorization interface, performing single sign-on authorization, acquiring a temporary authorization page,

the "access temporary grant" interface specifies the address: https:// www.ekuaibao.com/hellp/openapi/getting-started/temp-auth.

3. Analyzing a result returned by the temporary authorization interface, and redirecting the user page to a result page returned by the interface;

thus, the single sign-on function is completed.

In an alternative embodiment of the present invention, when the service to be interacted is a message service to be processed, the first service interconnection end is an easy-to-report financial reimbursement system, and the second service interconnection end is a generic micro OA system, (41) synchronizing the service to be interacted of the first service interconnection end includes:

(411) Acquiring an outbound message request carrying bill information sent by an easy-to-report financial reimbursement system, and acquiring request parameters in the bill information in the outbound message request;

(412) Acquiring bill details according to the request parameters, analyzing the bill details, and generating a to-be-processed outbound bill record;

(413) Determining whether a bill corresponding to the bill information is in an outbound bill record according to the request parameters;

(414) If not, newly adding a document record to be processed;

(415) If yes, judging whether the bill is updated, and if yes, updating;

(416) Analyzing the bill to obtain new bill details, and analyzing the new bill details to obtain the latest state of the bill in the quick-reporting financial reimbursement system;

(417) If the latest state is refused, acquiring a refused node of the bill according to the approval log record of the bill;

(418) If the reject node is a submitter, determining that a junction handling notification needs to be sent to the submitter;

(419) If the reject node is an intermediate node, determining that a to-be-handled notification needs to be sent to an intermediate node handling person;

(4191) Judging whether the current node is in a state table, wherein the current node is a submitter or an intermediate node;

(4192) If yes, and the notification is a transaction notification, modifying the transaction sending state to be sent;

(4193) If yes, modifying the to-be-sent state to be sent;

(4194) If not, the record is newly added;

(4195) If the latest state is archiving, a check notification is required to be sent to a submitter of the bill;

(4196) If the latest state is not refused or archived, determining whether the document has a change;

(4197) If the change exists, the current approver of the bill is obtained;

(4198) Judging whether the current approver and the current approving node are in a state table or not;

(4199) If not, the corresponding node is newly added, and the to-be-sent state of the newly added node is to-be-sent;

(42) Synchronizing the service to be interworking to a second service interworking end, comprising:

(421) And sending the message of the to-be-done notification or the message of the office notification to the micro-OA system.

Specifically, the to-Do message is integrated into the generalized micro OA:

1. in the configuration of the quick report single data flow, after the node is started, the outbound message node is configured. After a user submits a bill, the bill information is transmitted to the middleware through an outbound message node;

outbound message request path:

http://ykbplug.ehiger.com/outmsg/servlet.

parameters:

a. document ID: flowId

b. Title: title (title)

c. Encoding: code

d. Node ID: nodeId

2. The middleware, upon receiving the outbound message request, obtains the request parameters (mainly flowId). And calling an easy-to-report bill detail interface according to the requested flowId to acquire bill details.

The detail interface of the easy-to-report list shows the address:

https://www.ekuaibao.com/help/openapi/flows/get-forms-details.html。

after the receipt details are obtained, the receipt details are analyzed, an outbound receipt record to be processed is generated (specific fields refer to a to-be-processed receipt record table in a database design section), and whether the receipt is in the outbound receipt record table or not is judged according to the flowId. If the document does not exist, the record is newly added, and if the document does exist, whether the document is updated is judged according to the document logs content. If there is an update, then the update is made.

3. Returning 204 to the status of easy flash. Meanwhile, starting the thread and executing the bill analysis work; i.e., resolving a record in a t_if_outbound_message table (hereinafter referred to as a message table) into a t_if_bill_application_states record;

the method is mainly used for determining the contents of the following fields:

a, flowId, document ID;

stageName: node name;

operator, operator of the current node;

d, DOStatus is a to-be-sent state;

e, donestatus, already sent state;

f, overstatus, namely handling a knot sending state;

When the information to be handled of the bill is analyzed, the detail of the bill (the detail interface of the bill is described in the step 2) is firstly obtained, and the detail of the bill is analyzed so as to obtain the latest state of the bill on easy quick report;

4. if the current latest state of the bill is: reject, i.e., indicates that the document has been rejected. At this time, according to the approval log record of the bill, it is required to acquire which node the bill is rejected to:

a) Analyzing the 'next operator Id' according to the last record of the bill approval log (logs node) to judge the reject node of the bill;

b) If the nextOperator Id is empty, it indicates that the submitter is rejected. At this time, a check notification needs to be sent to the submitter;

c) If the nextOperationId is not null, it indicates a rejection to the intermediate node. At this time, a waiting notice needs to be sent to the intermediate node transactor;

d) Before sending a to-be-handled or a handling notification, setting all to-be-handled and handled of non-current nodes of a bill in a states table as sent according to three fields of a bill number (flowId), a node name (stageName) and an operator; and judging whether the current node exists in the states table according to the three fields.

i. If the notification exists and is a check notification, directly modifying the overstats to be sent;

if the notification exists and is to-do notification, directly modifying the doStatus to be sent;

if not, directly adding the record;

5. if the current latest state of the bill is: the aligned/paid indicates that the document has been approved. At this time, it is necessary to send a check notification to the document presenter:

a) Before sending the transaction notification, setting all nodes to be handled in the bill to be sent;

b) Checking whether the node exists in the states table or not, and skipping if the node exists; if not, newly adding a node, and setting an overStatus to be sent;

6. if the document is not currently up-to-date: reject/accepted/id, i.e., indicates that the document is still under approval, at this time, it is determined whether the document has a change by determining whether the document log md5 code matches the message table:

a) If the bill is changed, an easy-to-report interface for acquiring the approval state of the appointed bill is called to acquire the current approver (including the proxy approver) of the bill.

Easy quick report "obtain approval status of appointed document" interface description address:

https://www.ekuaibao.com/help/openapi/flows/get-approve-state.html。

b) Judging whether nodes and approvers exist in a states table or not according to the current approver and the current approver node, and if so, not performing any treatment; if the nodes do not exist, all nodes to be handled in front of the bill are set to be sent according to the flow Id of the bill; and newly adding a node, wherein the newly added node is to be sent;

7. starting a sending thread to send the message to be handled/already handled/transacted.

And the interface for the to-be-handled, the done and the done is provided by the client.

Sending to-be-handled:

reading all doStatus in the t_if_bill_application_states table as nodes to be sent; calling an interface provided by a client, and sending a message to be handled;

interface address:

Webservice:/services/ServiceMessageCustom

in the interface, the URL parameter path is:

http://ip:port/outmsg/reurluid＝**&flowId＝**

setting the currently recorded dortatus in the states table to be transmitted after the transmission is successful, and setting the dorestatus to be transmitted;

e) Send already done

i. Reading all doneStatus in the states table as nodes to be sent, calling interfaces provided by clients, and sending the handled messages; in general, the already-handled message interface is actually a modified interface;

interface address:

Webservice:/services/ServiceMessageCustom

in the interface, the URL parameter path is:

http://ip:port/outmsg/reurluid＝**&flowId＝**

setting the currently recorded donwttatus in the states table to be transmitted after the transmission is successful;

f) Transmitting office knot

i. Reading all overStatus in the status table as nodes to be sent, calling an interface provided by a client, and sending a transaction message;

interface address:

Webservice:/services/ServiceMessageCustom

in the interface, the URL parameter path is:

http://ip:port/outmsg/reurluid＝**&flowId＝**

setting the overStatus currently recorded in the states table to be transmitted after the transmission is successful;

so far, the whole to-be-sent flow process is completed.

And opening an easy-to-report page of the message to be handled, and finishing approval operation:

when the to-be-handled is sent, two URL parameters are arranged in the to-be-handled interface: PCURL/APPURL respectively represents the link address to be handled opened on the PC and the link address to be handled opened on the APP. In the to-Do send function, the URL path passed to the client interface is:

http://ip:port/outmsg/reurluid＝**&flowId＝**

1. clicking a document to be handled on the universal micro PC or the mobile phone by a user, and sending a request to the middleware;

2. after receiving the user request, the middleware analyzes the request parameters:

a) uid is user ID easy to report quickly;

b) flowId, document ID easy to report quickly.

And the middleware calls the temporary authentication interface which is easy to report quickly according to the uid and the flowId, and returns the bill page.

Easy flash temporary authorization interface description address:

https://www.ekuaibao.com/help/openapi/getting-started/temp-auth.html

3. the middleware redirects the user request to the bill detail page;

so far, the to-be-handled integration function of the whole bill is completed.

In an alternative embodiment of the present invention, when the service to be intercommunicated is a business trip application form service, the first service intercommunicating end is an easy-to-report financial reimbursement system, and the second service intercommunicating end is a generic micro OA system, (51) synchronizing the service to be intercommunicated of the first service intercommunicating end, including:

(511) Acquiring a business trip application form in an easy-to-report financial reimbursement system, and analyzing the business trip application form to confirm that a bill template is the business trip application form and a return stroke confirmation form;

(512) Determining whether a business trip application form already exists;

(513) If not, adding the bill, and marking whether the bill is synchronized to 0 in the bill synchronization state;

(514) If the bill exists, judging whether the bill of the business application form needs to be modified;

(515) If the document needs to be modified, modifying a document record of the business trip application form, and marking whether the document synchronization state is synchronized to 0;

specifically, the application form is synchronized locally to the middleware:

1. obtaining the maximum index record of the last synchronization from a local application form record table; when the index record value is 0 in the first acquisition;

2. calling an interface for acquiring a bill list by quick report to acquire a business trip application form;

easy-to-report list interface description address:

https://www.ekuaibao.com/help/openapi/flows/get-forms-sequences.html。

Interface parameters:

type: request; the return confirmation list is also a used easy-to-report business trip template;

Count:100

3. analyzing the response business trip application form data, and confirming that the bill template is: business trip application forms and return trip confirmation forms;

4. determining whether the bill exists in a local record list or not according to the sole application form flowid; if not, then add. And marking the synchronous state of the bill: whether or not it has been synchronized to 0;

5. if the bill exists, judging whether the bill needs to be modified according to the business trip person and the business trip time in the bill; if the document record in the local record table is required to be modified, modifying the document record in the local record table; and marking the synchronous state of the bill: whether or not it has been synchronized to 0.

To this end, the application form is synchronized to local logic completion

(52) Synchronizing the service to be interworking to a second service interworking end, comprising:

(521) Acquiring a currently stored unsynchronized business trip application form and a backhaul confirmation form;

(522) Inquiring whether a corresponding business trip application form exists or not when the return trip confirmation form is synchronized;

(523) If the bill is not in the micro OA system, synchronizing the travel planning of the bill to the micro OA system;

(524) And when the trip planning has no data, synchronizing the data of the main table into the detail.

Specifically, synchronize the application form to OA:

1. And acquiring a local unsynchronized business trip application form and a backhaul confirmation form. Synched=0;

2. judging a synchronous bill template according to the bill type, inquiring whether a corresponding business trip application form exists when the bill is confirmed by synchronous return, and firstly, not synchronizing if the corresponding business trip application form does not exist. According to the field assembly required by the corresponding OA bill template, partial city fields need to take the OA city ID and take the ID of the city table.

3. And synchronizing the journey planning of the bill into the OA detail, and synchronizing the data of the main table into the detail when the journey planning has no data.

Interface address:

urn:weaver.workflow.webservices.WorkflowService.doCreateWorkflowRequest；

4. the id returned by the OA is obtained. If the id is smaller than 0, namely the bill synchronization is abnormal, the synchronization result is written back according to the returned id. And setting the synchronized to 1 if successful, and not modifying if failed, and waiting for next continuous synchronization.

So far, the application form is synchronized to the OA logic completion.

In an optional embodiment of the present invention, when the service to be interacted is a project service, the first service interconnection end is a generic micro OA system, and the second service interconnection end is an easy-to-report financial reimbursement system, (61) synchronizing the service to be interacted of the first service interconnection end includes:

(611) Acquiring all items to be synchronized of the micro OA system;

(612) Judging whether the current project exists or not;

(613) If so, determining whether the current item has a change;

(614) If the current item is changed, updating the current item, and setting an execution action as updating;

(615) If not, the current item is newly added, and the execution action is set as the new addition;

(616) Traversing each currently stored target item, and searching item codes corresponding to the target items in the micro-OA system to judge whether the target items are in an item list returned by the micro-OA system;

(617) If the item list returned by the micro-OA system is not included, determining that the execution action corresponding to the target item is deletion;

specifically, synchronize items locally to middleware:

1. calling an interface generated by Wsdl of the OA to acquire all items needing to be synchronized; no synchronized items are needed, filtering has been done in OA.

The Wsdl address is as follows:

https://oa.qkmtech.com/services/ModeDateService；

2. judging whether the item exists in a local item table according to the item code;

if so, the item key fields are aligned: whether the fields of the project name, the project type, the project member, etc. are changed; if there is a change, the item is updated (set action to UPDATE); if there is no change, no treatment is needed;

if not, the item is newly added and the action is set as CREATE;

3. Reversely checking whether the local item table data is in an item list returned by the micro-OA;

traversing the local item table data, checking whether the item code of the micro OA is in item list data returned by the micro OA for each piece of data, and if so, indicating that the item does not need to be deleted; if not, the description item needs to be deleted. At this time, the action in the local item table is set to DELETE.

To this end, the project is synchronized to the local logic completion.

(62) Synchronizing the service to be interworking to a second service interworking end, comprising:

(621) Determining an execution action in the currently stored items as a target item for the new addition or the update or the deletion;

(622) Assembling the business entity object, if the execution action of the first target department is new or modified, updating the data in the business object in the easy-to-report financial reimbursement system according to the assembled business entity object;

(623) And if the execution action of the second target department is deletion, disabling the data in the corresponding business object in the quick-report financial reimbursement system.

Specifically, synchronizing local items to the easy-to-report;

1. acquiring items with local states of CREATE and UPDATE and DELETE;

2. assembling a business entity object according to the corresponding field, and when the project names are repeated in special cases, transmitting the names as project names+project codes;

3. Assembling corresponding aggregate data

If it is new or modified: and calling an easy quick report 'update business object data' interface to update data in the business object.

Easy flash update business object data interface description address: https:// www.ekuaibao.com/hellp/openapi/datalink/update-entity-data.html;

if it is deleted: and calling an easy-to-report 'update business object data' interface, and disabling the data in the business object.

4. And analyzing the quick-reporting data updating response result. If successful, updating the project table, wherein the synchronous state of the data is as follows: a none.

If the synchronization state fails, recording the failure reason, and updating the synchronization state as follows: update, when the next task is executed, synchronizing again;

thus, the project is synchronized to the logical completion of the easy-to-report.

The method of business interworking is also capable of (71) synchronizing vendor invoices to middleware local:

1. synchronizing the supplier invoice to a local timed task start;

2. and calling an interface of the SAP to acquire all the provider invoices.

The SAP interface addresses are as follows:

https://my300370.saps4hanacloud.cn/sap/opu/odata/sap/API_SUPPLIERINVOICE_PROCESS_SRV/A_SupplierInvoice？$expand＝to_SuplrInvcItemPurOrdRef,to_SupplierInvoiceTax；

3. judging whether the invoice exists in a local supplier invoice table according to the supplier invoice code;

if so, the invoice related fields are compared and a determination is made as to whether an update is required? If the UPDATE is needed, setting the action as UPDATE; if no update is needed, directly skipping;

If the invoice does not exist, the invoice is newly added to be recorded in a local invoice table; and setting action as CREATE;

4. reversely checking the local invoice record table data, and judging whether the data is in a data list returned by the SAP;

traversing the data of the local invoice record table, checking whether invoice coding codes are in an invoice list returned by the SAP or not for each piece of data, and if so, indicating that the invoice does not need to be deleted; if not, the invoice is described as requiring deletion. At this time, the action in the local invoice record table is set to DELETE.

To this end, the synchronization of the supplier invoice to the local logic is completed.

(72) Synchronizing local supplier invoices to easy flash:

1. synchronizing the supplier invoice to a timing task start which is easy to report quickly;

2. obtaining supplier invoices with local states of CREATE and UPDATE and DELETE;

assembling business entity objects according to corresponding fields

The corresponding fields are as follows:

wherein, invoice details are required to be acquired according to invoice codes so as to acquire corresponding collection unit names and collection unit codes,

the invoice detail interface address is obtained as follows:

https:// my300370.SAPs4 halcycloud.cn/SAP/opu/odata/SAP/api_purshapeoreder_process_srv/a_purchaseorder ('invoice')? Expansion = to_PurchaseOrderItem/to_ScheduleLine/to_SubcontactionComponent

3. Assembling corresponding aggregate data

to this end, the supplier invoice is synchronized to the logical completion of the easy flash report.

The business intercommunication method of the invention realizes the data communication between the micro OA and the easy-to-report financial reimbursement system, and the business intercommunication between the micro OA and the easy-to-report financial reimbursement system, and the plug-in service meets the customized requirements.

The middleware services of the micro-OA system and the quick-reporting financial reimbursement system are constructed, so that data intercommunication and service interconnection are performed on service scenes, such as organization information data synchronization, department personnel data synchronization, single sign-on, to-do information, role synchronization, file synchronization, bill synchronization, supplier invoice and the like, of the micro-OA system and the quick-reporting financial reimbursement system.

Embodiment two:

the embodiment of the invention also provides a service intercommunication device which is mainly used for executing the service intercommunication method provided in the first embodiment of the invention, and the service intercommunication device provided in the embodiment of the invention is specifically introduced below.

Fig. 2 is a schematic diagram of an apparatus for service interworking according to an embodiment of the present invention, and as shown in fig. 2, the apparatus mainly includes: a first synchronization unit 10 and a second synchronization unit 20, wherein:

the first synchronization unit is configured to synchronize a service to be interworking at a first service interworking end, where the first service interworking end includes: a micro-OA system or an easy-to-report financial reimbursement system;

the second synchronization unit is configured to synchronize the service to be interacted to a second service interworking end, where the second service interworking end includes: the universal micro OA system or the quick-reporting financial reimbursement system, and the second business interconnection end is different from the first business interconnection end.

In an embodiment of the present invention, a device for service interworking is provided, which is applied to middleware services, and includes: synchronizing a service to be communicated of a first service communication end, wherein the first service communication end comprises: a micro-OA system or an easy-to-report financial reimbursement system; synchronizing the service to be communicated to a second service communicating end, wherein the second service communicating end comprises: the universal micro OA system or the quick-reporting financial reimbursement system, and the second business interconnection end is different from the first business interconnection end. According to the service intercommunication device, the middleware service is used for carrying out data intercommunication and service interconnection on service scenes of the high-frequency use of the micro OA system and the quick-reporting financial reimbursement system, so that the technical problem that the service intercommunication of the micro OA system and the quick-reporting financial reimbursement system can not be realized in the prior art is solved.

The device provided by the embodiment of the present application has the same implementation principle and technical effects as those of the foregoing method embodiment, and for the sake of brevity, reference may be made to the corresponding content in the foregoing method embodiment where the device embodiment is not mentioned.

As shown in fig. 3, an electronic device 600 provided in an embodiment of the present application includes: a processor 601, a memory 602 and a bus, said memory 602 storing machine readable instructions executable by said processor 601, said processor 601 communicating with said memory 602 via the bus when the electronic device is running, said processor 601 executing said machine readable instructions to perform the steps of the method of interworking as described above.

In particular, the memory 602 and the processor 601 can be general-purpose memories and processors, which are not limited herein, and the method for interworking service can be performed when the processor 601 runs a computer program stored in the memory 602.

The processor 601 may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in the processor 601 or instructions in the form of software. The processor 601 may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU for short), a network processor (Network Processor, NP for short), etc.; but may also be a digital signal processor (Digital Signal Processing, DSP for short), application specific integrated circuit (Application Specific Integrated Circuit, ASIC for short), off-the-shelf programmable gate array (Field-Programmable Gate Array, FPGA for short), or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software modules in a decoding processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory 602, and the processor 601 reads information in the memory 602 and performs the steps of the above method in combination with its hardware.

It should be noted that: like reference numerals and letters in the following figures denote like items, and thus once an item is defined in one figure, no further definition or explanation of it is required in the following figures, and furthermore, the terms "first," "second," "third," etc. are used merely to distinguish one description from another and are not to be construed as indicating or implying relative importance.

Finally, it should be noted that: the above examples are only specific embodiments of the present application, and are not intended to limit the scope of the present application, but it should be understood by those skilled in the art that the present application is not limited thereto, and that the present application is described in detail with reference to the foregoing examples: any person skilled in the art may modify or easily conceive of the technical solution described in the foregoing embodiments, or perform equivalent substitution of some of the technical features, while remaining within the technical scope of the present disclosure; such modifications, changes or substitutions do not depart from the spirit of the corresponding technical solutions. Are intended to be encompassed within the scope of the present application. Therefore, the protection scope of the application is subject to the protection scope of the claims.

Claims

1. A method of business interworking, applied to a middleware service, the method comprising:

2. The method of claim 1, wherein synchronizing the service to be interworking at the first service interworking end when the service to be interworking is a department service, the first service interworking end is a generic OA system, and the second service interworking end is an easy-to-report financial reimbursement system, comprises:

invoking a department interface provided by the micro-OA system to acquire all departments;

detecting whether the current department exists according to the department ID of the current department provided by the micro-OA system;

determining an execution action according to a detection result, and executing the execution action, wherein when the detection result is non-existence, the corresponding execution action is newly added, and when the detection result is existence and needs to be updated, the corresponding execution action is updated;

Traversing each currently stored target department, searching a department ID corresponding to the target department in the micro-OA system to judge whether the target department is in a department list returned by the micro-OA system;

if the corresponding execution action is not in the department list returned by the micro-OA system, determining that the corresponding execution action of the target department is deletion;

synchronizing the service to be interacted to a second service interaction end, including:

determining an execution action in the currently stored departments as a target department for new addition or update or deletion;

if the execution action of the first target department is newly added, judging whether an easy-to-report ID corresponding to the first target department exists or not;

if the easy-to-report ID does not exist, checking whether the first target department exists in the easy-to-report financial reimbursement system;

if the first target department does not exist in the quick report financial reimbursement system, the first target department is newly added in the quick report financial reimbursement system;

if the first target department exists in the quick report financial reimbursement system, information of the first target department is modified in the quick report financial reimbursement system;

If the execution action of the second target department is updated, modifying the information of the second target department in the easy-to-report financial reimbursement system;

and if the execution action of the third target department is deletion, disabling the third target department in the quick report financial reimbursement system.

3. The method of claim 1, wherein synchronizing the service to be interworking at the first service interworking end when the service to be interworking is employee data, the first service interworking end is a generic OA system, and the second service interworking end is an easy-to-report financial reimbursement system, comprises:

invoking an employee data interface provided by the generalized micro OA system to acquire all employee data;

detecting whether the current employee data exists according to the employee ID of the current employee data provided by the micro-OA system;

determining an execution action according to a detection result, and executing the execution action, wherein when the detection result is non-existence, the corresponding execution action is newly added, when the detection result is existence and needs to be updated, the corresponding execution action is updated, and when the detection result is that the current employee data display that the corresponding current employee is away, the corresponding execution action is deleted;

if the execution action of the first target employee data is newly added, acquiring a first quick report department ID in corresponding department information according to a department to which the employee in the first target employee data belongs, and further newly adding the first target employee data in a department corresponding to the first quick report department ID;

if the execution action of the second target employee data is update, acquiring a second quick report department ID in corresponding department information according to a department to which the employee in the second target employee data belongs, and further updating the second target employee data in a department corresponding to the second quick report department ID;

if the execution action of the third target employee data is deletion, disabling the third target employee data on the easy-to-report financial reimbursement system;

and modifying the execution actions of the first target employee data, the second target employee data and the third target employee data to be none.

4. The method of claim 1, wherein synchronizing the service to be interworking at the first service interworking end when the service to be interworking is a single sign-on service, the first service interworking end is a generic micro OA system, and the second service interworking end is an easy-to-report financial reimbursement system, comprises:

Acquiring a work number of the staff single sign-on sent by the generalized micro OA system, wherein a single sign-on entrance is configured in the generalized micro OA system, and the work number is input by the staff at the single sign-on entrance;

determining a corresponding employee ID easy to report according to the work number, and calling an easy to report temporary authorization interface to perform single sign-on authorization so as to acquire a temporary authorization page;

and analyzing the temporary authorization page, and redirecting the employee page to the temporary authorization page.

5. The method of claim 1, wherein synchronizing the service to be interworking at the first service interworking end when the service to be interworking is a message service to be handled, the first service interworking end is an easy-to-report financial reimbursement system, and the second service interworking end is a generic micro OA system, comprises:

acquiring an outbound message request carrying bill information sent by the quick-report financial reimbursement system, and acquiring request parameters in the bill information in the outbound message request;

acquiring bill details according to the request parameters, analyzing the bill details, and generating a to-be-processed outbound bill record;

Determining whether a bill corresponding to the bill information is in an outbound bill record according to the request parameters;

if not, the document record to be processed is newly added;

if yes, judging whether the bill is updated, and if yes, updating;

analyzing the bill to obtain new bill details, and analyzing the new bill details to obtain the latest state of the bill in the quick-reporting financial reimbursement system;

if the latest state is refused, acquiring a refused node of the bill according to the approval log record of the bill;

if the reject node is a submitter, determining that a check notification needs to be sent to the submitter;

if the reject node is an intermediate node, determining that a to-do notification needs to be sent to an intermediate node transactor;

judging whether a current node is in a state table, wherein the current node is a submitter or an intermediate node;

if yes, and the notification is a transaction notification, modifying the transaction sending state to be sent;

if yes, modifying the to-be-sent state to be sent;

if not, the record is newly added;

if the latest state is archiving, a check notification is required to be sent to a submitter of the bill;

If the latest state is not refused or archived, determining whether the document has a change;

if the change exists, the current approver of the bill is obtained;

judging whether the current approver and the current approver node are in a state table or not;

if not, the corresponding node is newly added, and the to-be-sent state of the newly added node is to-be-sent;

and sending the message of the to-be-handled notification or the message of the handling notification to the micro-OA system.

6. The method of claim 1, wherein synchronizing the service to be communicated at the first service interworking end when the service to be communicated is a business trip application service, the first service interworking end is an easy-to-report financial reimbursement system, and the second service interworking end is a generic micro OA system, comprises:

acquiring a business trip application form in the easy-to-report financial reimbursement system, and analyzing the business trip application form to confirm that a bill template is a business trip application form and a return stroke confirmation form;

determining whether the business trip application form already exists;

if not, adding the bill, and marking whether the bill is synchronized to 0 in the bill synchronization state;

If so, judging whether the bill of the business trip application form needs to be modified;

if the bill record of the business trip application form is required to be modified, modifying the bill record of the business trip application form, and marking whether the bill synchronization state is synchronized to 0;

acquiring a currently stored unsynchronized business trip application form and a backhaul confirmation form;

when synchronizing the return confirmation list, inquiring whether a corresponding business trip application list exists or not;

if not, synchronizing the journey planning of the bill into the micro-OA system;

and when the trip planning has no data, synchronizing the data of the main table into the detail.

7. The method of claim 1, wherein synchronizing the service to be interworking at the first service interworking end when the service to be interworking is a project service, the first service interworking end is a generic micro OA system, and the second service interworking end is an easy-to-report financial reimbursement system, comprises:

acquiring all items to be synchronized of the generic micro OA system;

judging whether the current project exists or not;

if so, determining whether the current item has a change;

if the current item is changed, updating the current item, and setting an execution action as updating;

If not, the current item is newly added, and the execution action is set to be newly added;

traversing each currently stored target item, and searching item codes corresponding to the target items in the micro-OA system to judge whether the target items are in an item list returned by the micro-OA system;

if the execution action is not in the item list returned by the micro-OA system, determining that the execution action corresponding to the target item is deletion;

determining an execution action in the currently stored items as a target item for the new addition or the update or the deletion;

assembling a business entity object, if the execution action of the first target department is new or modified, updating data in the business object in the easy-to-report financial reimbursement system according to the assembled business entity object;

and if the execution action of the second target department is deletion, disabling the data in the corresponding business object in the easy-to-report financial reimbursement system.

8. An apparatus for interworking of traffic, applied to a middleware service, the apparatus comprising:

The second synchronization unit is configured to synchronize the service to be interworking to a second service interworking end, where the second service interworking end includes: the generic micro OA system or the easy-to-report financial reimbursement system, and the second service interconnection end is different from the first service interconnection end.

9. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the steps of the method of any of the preceding claims 1 to 7 when the computer program is executed.

10. A computer readable storage medium storing machine executable instructions which, when invoked and executed by a processor, cause the processor to perform the method of any one of the preceding claims 1 to 7.