The third-party interface document of wechat is relatively simple, many things have not been written out, and the logic is also difficult to understand. Here I will clarify the table structure used in the last project

When using the multi-tenant architecture, we can combine the ISV mode of wechat and the multi-tenant mode, that is, each customer’s enterprise wechat corresponds to one tenant. In order to achieve the automation of the program as much as possible and increase the scalability, the following three tables are mainly involved in the project (the tenant ID is collectively called corpInfoId below, Wechat id: wxCorpId) :

1. Saas_corp_info mainly associates tenant IDS with wechat ids. Each tenant has one data, and some tenant related data can also be persisted



Wf_push_agent_id is the application ID pushed by the workflow. It is different for each customer's enterprise wechat account and can be obtained by interface when the customer installs the approval suiteCopy the code

2. Saas_suite_info Each suite has one record, and the suite information is persisted. In particular, suite_ticket, suite_token, and pre_auth_code have valid dates



Is_contact_suite indicates whether it is an address book suite, which can be obtained by interface when creating a suite. Is_workflow_suite indicates whether it is an approved suite, which can be obtained by interface when creating a suite.Copy the code

3. Saas_suite_corp records the correspondence between customers’ wechat accounts and suites. For each suite installed by customers, there is a record, including token and permanent codes.