规划 JSON 服务提供程序
通常，应构造 CICS® 应用程序以确保业务逻辑与通信逻辑分离。 遵循该方法有助于您直接在 Web Service 提供程序中部署新的和现有的应用程序。 在某些情况下，您将需要在应用程序与 CICS Web Service 支持之间插入简单包装程序。
图 1 显示了一个已分区的典型应用程序，以确保通信逻辑与业务逻辑之间的分离。图 1。 已经分区以执行通信逻辑和业务逻辑的应用程序 
图 2。 将 CICS 应用程序作为 Web Service 提供程序进行简单部署 
要使用这个简单的模型，必须符合以下条件：
- 使用 z/OS® Connect 在 JSON 模式或 Swagger 文档与应用程序数据结构之间生成映射时:
- z/OS Connect Enterprise Edition 支持比 CICS 助手支持的更广泛的应用程序副本结构。 在大多数情况下，将不支持这些副本。 否则，您可以在 z/OS Connect 服务与业务逻辑之间插入包装程序。
- 使用 CICS 助手在 JSON 模式和应用程序数据结构之间生成映射时:
- CICS 助手必须支持业务逻辑接口中使用的数据类型。 如果情况并非如此，那么必须在 CICS Web Service 支持与业务逻辑之间插入包装程序。
部署现有应用程序时，您还需要一个包装程序来提供符合现有 Web Service 描述的服务：如果使用助手来处理 Web Service 描述，那么生成的数据结构很难将接口匹配到业务逻辑。
- 当您不使用 CICS 助手时:
- 服务提供程序流水线中的消息处理程序必须直接与业务逻辑进行交互。
使用包装程序
当 CICS 助手无法生成代码以直接与业务逻辑交互时，请使用包装程序。 例如，业务逻辑接口可能使用 CICS 助手无法直接映射到 JSON 消息的数据结构。 在这种情况下，您可以使用包装程序提供任何所需的其他数据操作：
- 在两个数据结构之间移动数据
- 使用其现有接口调用业务逻辑
处理错误
如果您计划使用 CICS 助手，那么还应该考虑如何在出错时回滚更改。 当收到来自服务请求程序的 JSON 请求消息时，CICS 将会转换 JSON 消息，然后再将其传递到应用程序。 如果转换期间发生错误，CICS 不会自动回滚已经对该消息执行的任何工作。 例如，如果计划使用流水线中的处理程序在 JSON 消息上添加额外的处理，那么您需要决定是否应该回滚已执行的可恢复更改。
例如，在出站 JSON 消息上，当服务提供程序将响应消息发送至服务请求程序时，如果 CICS 在生成响应 JSON 消息时遇到错误，那么应用程序所作的所有可恢复更改都会自动撤销。 您应该考虑是否可以针对您的应用程序添加同步点。