Decoupling Front‑End and Back‑End with a Dedicated TPS Microservice for Third‑Party Push Integration

In many projects, front‑end pages need to call several back‑end controllers for push notifications, leading to high coupling and duplicated code when third‑party services change.

Coupling Issues

When a push interface involves multiple channels, each settlement type may expose its own controller, and common third‑party calls are duplicated across them.

Front‑End Problems

Multiple controllers must be invoked with different parameters; any back‑end change forces updates on many pages.

Permission configuration is required for many buttons.

Back‑End Problems

Each business interface needs its own method to call the third‑party push, creating repetitive code.

When a third‑party API changes, many back‑end services must be modified.

Solution

Create a dedicated microservice (named Tps ) that encapsulates all third‑party push logic and extracts common parameters.

Other business services (order, settlement, supplier, etc.) call the Tps service via a unified Feign interface, eliminating direct third‑party handling.

Business services focus only on their own service‑layer logic without dealing with integration details.

The overall flow is illustrated in the diagram below:

Specific Implementation

Tps Service

The Tps service exposes a Feign interface that front‑end calls uniformly.

// Interface for third‑party service
public interface IKingdeeManagementService {
    Boolean push(KingdeePushCO.Request request);
}

Feign implementation:

@Slf4j
@Service
public class KingdeeManagementServiceImpl implements IKingdeeManagementService {
    @Autowired
    private ApplicationContext applicationContext;
    @Autowired
    private KingdeeThirdSettingService kingdeeThirdSettingService;

    @Override
    public Boolean push(KingdeePushCO.Request request) {
        KingdeeBusinessPushServiceEnum enumVal = KingdeeBusinessPushServiceEnum.getKingdeePushServiceEnumByType(request.getBusinessType());
        IKingdeeBusinessPushService service = (IKingdeeBusinessPushService) applicationContext.getBean(enumVal.getClazz());
        try {
            R
result = service.pushKingdee(request);
            return true;
        } catch (BeansException e) {
            log.error("Current type not implemented, contact developer");
            throw new ServiceException("Current type not implemented, contact developer");
        }
    }
}

Enum definition for routing:

public enum KingdeeBusinessPushServiceEnum {
    private Class clazz;
    private Integer type;
    private String interFaceName;
    KingdeeBusinessPushServiceEnum(Class clazz, Integer type, String interFaceName) {
        this.clazz = clazz;
        this.type = type;
        this.interFaceName = interFaceName;
    }
    // Example constant
    RECEIPT_VOUCHER(IJaKingdeeBillClient.class, KingdeeBusinessTypeConstant.RECEIPT_VOUCHER, KingdeeSettingEnum.INTERFACE_TYPE_JA_RECEIPT_VOUCHER.getCode()),
    ;
}

Key enum fields:

clazz : the Feign interface class provided by the business system.

type : integer value sent from front‑end to map to a specific Feign implementation.

interFaceName : name of the third‑party interface to be invoked.

Business System Integration

For example, the BMS service implements the Feign interface and delegates the push call to the Tps service. Factory utilities such as JaKingdeeFactoryUtil and JaKingdeeServiceFactory are used to obtain singleton instances and avoid repeated bean creation.

Conclusion

The presented design centralizes third‑party push calls, reduces coupling, simplifies permission management, and makes future third‑party changes easier to handle. Additional considerations such as result caching, timeout handling, and fallback strategies can be layered on this foundation.