Solving Coupling Issues with a Dedicated TPS Microservice and Feign Integration

In many scenarios, such as a push notification interface that needs to interact with multiple third‑party channels (e.g., a settlement service calling Kingdee ERP), each business type often requires a separate controller, leading to high coupling between front‑end pages and back‑end APIs.

Front‑end issues

Multiple controllers must be called, each with different parameters; any change in a back‑end API forces changes in many pages.

Permission configuration must be duplicated for many buttons.

Back‑end issues

Each business interface contains repetitive code for calling third‑party push services, increasing coupling.

When a third‑party API changes, a large amount of back‑end code must be modified.

Solution

Create a dedicated microservice (named TPS) that solely handles integration with third‑party services. The TPS service encapsulates common parameters and exposes a unified Feign interface; other business services (order, settlement, supplier) call this interface instead of directly invoking third‑party APIs.

Business services only need to implement their service‑layer logic; the TPS service takes care of the integration details.

Implementation details

TPS service

The TPS service defines a Feign interface:

public interface IKingdeeManagementService {
    Boolean push(KingdeePushCO.Request request);
}

And its implementation:

@Slf4j
@Service
public class KingdeeManagementServiceImpl implements IKingdeeManagementService {

    @Autowired
    private ApplicationContext applicationContext;
    @Autowired
    private KingdeeThirdSettingService kingdeeThirdSettingService;

    @Override
    public Boolean push(KingdeePushCO.Request request) {
        KingdeeBusinessPushServiceEnum kingdeePushServiceEnum =
            KingdeeBusinessPushServiceEnum.getKingdeePushServiceEnumByType(request.getBusinessType());

        IKingdeeBusinessPushService kingdeePushService = null;
        try {
            kingdeePushService = (IKingdeeBusinessPushService) applicationContext.getBean(
                kingdeePushServiceEnum.getClazz());
        } catch (BeansException e) {
            log.error("Current type not implemented, please contact developer");
            throw new ServiceException("Current type not implemented, please contact developer");
        }
        R
result = kingdeePushService.pushKingdee(request);
        return true;
    }
}

An enum maps business types to the corresponding Feign interface class, type code, and third‑party interface name:

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 entry
    RECEIPT_VOUCHER(IJaKingdeeBillClient.class,
        KingdeeBusinessTypeConstant.RECEIPT_VOUCHER,
        KingdeeSettingEnum.INTERFACE_TYPE_JA_RECEIPT_VOUCHER.getCode()),
    ;
}

The enum provides the Feign interface (clazz), the integer type sent from the front‑end, and the name of the third‑party interface to invoke.

Business system integration

Business services (e.g., BMS) inherit the TPS Feign interface and override the push method. A factory (JaKingdeeFactoryUtil) creates the appropriate service implementation using double‑checked locking and a pessimistic lock to avoid multiple instantiations, while SpringContextUtils retrieves beans.

Conclusion

The presented design unifies third‑party calls through a dedicated TPS microservice, reduces code duplication, lowers coupling, and provides a clear extension point for caching, timeout handling, and fallback strategies.