RHPAM 7.9 standalone部署Business Central无法显示已运行的Kie Server

高优先级错配（直接导致连接失效的核心原因） #

• 配置项完全未被加载：当前sample-standalone-config.yml中，所有与Kie Server连接相关的参数全部位于yaml根节点下，不在swarm:配置的有效解析范围内。Thorntail standalone版Business Central仅会读取swarm:节点下的配置项，根节点其他位置的内容会被完全忽略，导致BC启动后根本没有拿到任何Kie Server的地址、凭证参数，也不会发起主动连接尝试，因此日志中不会出现任何报错。
  调整方案二选一：
  1. 将所有Kie Server连接配置移动到swarm.system-properties节点下，保证能被配置解析器识别：

     swarm:
       # 原有swarm下的安全、日志、undertow配置保持不变
       system-properties:
         org.kie.server.id: SpringBoot
         org.kie.server.user: kieserver
         org.kie.server.pwd: kieserver1!
         org.kie.server.location: http://localhost:8090/rest/server
         org.kie.server.mode: development
         org.kie.server.bypass.auth.user: true
         org.kie.server.controller: http://localhost:8080/rest/controller
         org.kie.server.controller.user: kieserver
         org.kie.server.controller.pwd: kieserver1!
     

  2. 直接在启动命令中通过-D参数传递上述所有配置，绕开yaml解析逻辑：

     java -jar rhpam-7.9.0-business-central-standalone.jar -s sample-standalone-config.yml \
     -Dorg.kie.server.id=SpringBoot \
     -Dorg.kie.server.user=kieserver \
     -Dorg.kie.server.pwd=kieserver1! \
     -Dorg.kie.server.location=http://localhost:8090/rest/server \
     -Dorg.kie.server.mode=development \
     -Dorg.kie.server.bypass.auth.user=true \
     -Dorg.kie.server.controller=http://localhost:8080/rest/controller \
     -Dorg.kie.server.controller.user=kieserver \
     -Dorg.kie.server.controller.pwd=kieserver1!
     

• Business Central侧缺失连接所需的用户凭证：当前BC的ApplicationRealm使用本地属性文件做用户认证，未将kieserver用户写入认证文件，即使配置被加载，BC发起连接时的身份校验也无法通过。
  • 需在BC运行目录下的application-users.properties文件中追加：kieserver=kieserver1!
  • 需在同目录下的application-roles.properties文件中追加：kieserver=admin,kie-server,rest-all,user,process-admin
• 跨版本兼容性冲突：当前部署的RHPAM 7.9对应的官方匹配Kie Server版本为7.13.x系列，与当前使用的7.44版本Spring Boot Starter构建的Kie Server存在REST API不兼容问题，即使连接参数全部配置正确，跨版本的Kie Server也无法被BC正常识别和纳管。需将Kie Server的Spring Boot Starter版本降级为与RHPAM 7.9匹配的版本。

中优先级配置冲突（配置加载完成后会导致连接中断的问题） #

• Kie Server侧CORS规则配置冲突：当前WebSecurityConfig中设置allowedOrigins("*")同时开启allowCredentials(true)，在Spring Security高版本中，该组合会触发CORS过滤器拦截所有携带认证头的请求，且不会输出明确的错误日志。
  调整：将原CORS规则中的configuration.setAllowedOrigins(Arrays.asList("*"))替换为configuration.setAllowedOriginPatterns(Arrays.asList("*"))，同时在安全配置中放开所有OPTIONS预检请求的访问权限：

  @Override
  protected void configure(HttpSecurity http) throws Exception {
      http
      .cors().and()
      .csrf().disable()
      .authorizeRequests()
          .antMatchers(HttpMethod.OPTIONS, "/**").permitAll()
          .antMatchers("/rest/*").authenticated()
          .and()
      .httpBasic();
  }
  

• BC侧跨域规则导致回连405：当前undertow的过滤器配置仅添加了跨域响应头，未对OPTIONS预检请求做放行，会导致Kie Server主动回连BC时的预检请求返回405错误。可直接移除BC侧所有全局CORS响应头配置，因为BC与Kie Server之间是服务端直连通信，不存在浏览器跨域限制，无需额外配置CORS规则。

非核心问题说明 #

• 9990管理端口页面出现的null值，是因为当前Thorntail standalone版的管理接口未配置对应的管理员用户凭证，与BC和Kie Server的核心连接逻辑无关，可后续在application-users.properties中添加管理员用户、配置对应角色后解决，不影响业务功能。

连接验证方法 #

1. 完成上述配置调整后，分别启动Kie Server与Business Central，等待BC启动完成
2. 观察BC启动日志，当出现Successfully resolved KIE Server字样时说明连接建立成功
3. 进入BC的"Server Management"页面，可直接看到已注册的SpringBoot Kie Server实例
4. 若连接失败，可手动在Server Management页面添加Kie Server配置，填入地址、用户名、密码后点击测试连接，快速定位剩余配置问题。

内容的提问来源于stack exchange，提问作者js6yaml