ABF Platform Configuration Center: Building a Configuration-Driven Middle-Office Development System

The configuration center of the ABF platform, also known as the rendering center, is responsible for all application rendering data and rendering function configurations.

In the process of middle-office R&D, we discovered universal patterns in middle-office systems. Multiple systems have nearly 100% reusability in rendering functions. For example, common middle-office pages include search display tables, adding table content, editing table content, deleting table content, and other similar business forms. Therefore, the goal of the configuration center is to serve as a "middle-office factory assembly line" configurator to achieve efficient business system development.

1. Application Configuration — The Door and Key

Unlike B2B and B2C projects, most middle-office projects target internal personnel. In many cases, business users only need different "doors" (domains) and the same "key" (internal network account). The rendering center first completes rendering corresponding applications based on different user access domains. After that, the same key can be used to quickly create a middle-office "door" and "key". For the ABF platform, one domain uniquely corresponds to one application.

2. Page Configuration — Various Rooms

Below applications, the ABF platform introduces the concept of pages, implementing each page independently using MPA thinking. Each page has its own unique appearance and functions while inheriting the application's configuration overall. This enables convenient system functionality expansion. Want a new functional page? Just create a new "room" (page)! Technically, the ABF rendering center uses domain and environment variables (daily/pre/prod) to form the unique identifier for applications. For routing matching rules, we chose servlet's url-pattern matching rules, which can satisfy precise matching rules and facilitate page routing configuration through /* and /** matching rules.

3. Permission Control — Face Recognition

Since the key is the same, it's inevitable that anyone with the key can enter and exit all "rooms" in all "houses," which is not what business users would want. Therefore, the configuration center adds "face recognition" (permission verification) to each "room" in each "house," enabling access restrictions for different pages and modules through permission verification. To more conveniently control permission authorization, we introduced the concept of tenants—all users who can access an application are tenants. Each application administrator can only manage permissions for their application's corresponding tenants, avoiding privilege escalation.

For permission technical implementation, we first defined a unified user information structure including user ID, name, avatar and other fields, ensuring this user information structure applies to multiple login systems. The unification of user information structure is the prerequisite for permission verification. Then permission control is completed through the association verification of user ID, application ID, and permission point. Application ID verification is necessary because without it, permission points would be open to everyone. A permission administrator could manage permission points for all applications. In actual development, we need to manage our own permission points. Therefore, we implemented application isolation on permission points. This isolated application ID has a corresponding ID in the user information structure, called tenant ID—each logged-in user has a dedicated tenant corresponding to them, which maps one-to-one with the application. Tenant A's users cannot verify permissions using Tenant B's permission points, ensuring isolation between permission points.

Our login process becomes: account password verification → tenant selection → permission verification → page matching. A user may have multiple tenant identities and needs to choose which tenant identity to use when logging in.

4. Layout Configuration — Standardized House Specifications

On one hand to improve efficiency, on the other hand for the standardization of the entire middle-office ecosystem. We provide a unified layout component for middle-offices, defining how a house's "rooms" should be arranged. We also provide configuration of "room layout diagrams" (menus). Decoupling application navigation and menu configuration from source code greatly increases system extensibility.

5. Custom Extensions — Creating Personalized Rooms

After meeting 99% of similar configurations, what if business users want a unique room? Don't worry! The configuration center provides a custom "room" extension mechanism. Similar to functional extension methods, the configuration center provides unified input parameters including user identity verification information, domain access information, application configuration information, and more. As long as the processed function format meets the configuration center's specified format, custom "room decoration" can be implemented.

Through the above configuration capabilities, the ABF platform's configuration center achieves 90% of what's needed to create middle-office applications. Creating applications and pages through the ABF platform configuration center can quickly complete system creation and launch.