Scheme design of sharing public number of micro-station

Business model

As a result of the hot, there has been a lot of public number two times the development of the platform company. The main business is to develop two times for the customer's public number, providing services such as micro-portals and micro-mart. Usually the customer applies a unique business ID on the platform, then binds their public number to this ID, so the public number and the micro-station are one by one corresponding

However, the threshold for applying for a public number, especially a certification service number, is relatively high. Division I because of the characteristics of the industry, users are basically very difficult to apply to the qualification. So our model is provided by our company to provide a shared public number, users can use the shared public number of services provided, and if users themselves can provide the public number, but also support the private public number access to the platform

URL planning

As mentioned earlier, most platform companies provide a micro-site URL similar to this: www.pt.com/wsite/:p tid/shop, and then according to Ptid in the path, you can then find this ID corresponding to the public information (including App_id,app_secret, etc.) from the associated table. As I said earlier, the platform ID and the public number of this model correspond to one by one, so we can do this.

But mixed mode, the URL needs to take the public number of identification, so the URL is similar: www.pt.com/wsite/:appId/:p tid/shop, more than a appId, so as to distinguish, this page is currently open from which public number. If the URL does not have this identity, because a page can be opened from the shared public number, or from the private public number, then there is no way to determine the current public number

For example, the following scenario, from the OAuth page to the micro-station, get the code of the visitor, then you need to call the public platform interface according to code to get open_id, the interface needs to app_id as a parameter, the URL of the AppID can function

Data Model Design

When you save a fan's binding relationship in the database, the blending mode also needs to save the app_id field more than once. For example, the business system has member_id, then the dedicated mode, may only need to save member_id and open_id is enough, because according to MEMBER_ID, is enough to find the platform unique ID, and then associated to find app_id, so open_id corresponding to which app _ID is the only one.

But the model, which shares the public number and the private-public number mix, does not work. Because the end user may be bound from the private public number, or from the shared public number binding, so light with member_id, can not uniquely determine the app_id, so in the database table, also need to save app_id, to uniquely identify the fan, properly call the interface

For example, the following scenario, when the user to the store after consumption, to send him a template message. Although according to member_id found OPEN_ID, but also need app_id to invoke the template message interface, if not save app_id, light with member_id, is not found

Summarize

The key is that our platform not only provides shared public numbers, but also supports mixed mode for private and shared numbers. Therefore, all involved in the user identification of the place, need to take the initiative to carry app_id information. The platform ID and the public number one by one corresponding to the scheme, it is not necessary, because the platform ID can be associated to find the corresponding public number

Scheme design of sharing public number of micro-station