企业官网建设流程全解析

• 示例工程
• 教程
• 后端

本文以 aws-doc-sdk-examples 仓库中 sap-abap/services/hll/README.md 为核心，讲解如何在 SAP ABAP 环境中通过 AWS SDK for SAP ABAP 调用 AWS HealthLake 的全部 13 个单动作 API：FHIR 数据存储（Data Store）的创建、描述、列出与删除，FHIR 导入/导出任务的启动、描述与列出，以及资源的标签管理。读完本文，你将掌握 HealthLake 在 ABAP 侧的完整编程模型（会话创建 → 服务工厂 → 方法调用 → 异常处理），了解每个动作的入参类型、响应对象结构，并能通过 SE24 调用示例方法或在 ABAP 单元测试中验证全链路行为。

概览：HealthLake 与 SAP ABAP 的集成方式

AWS HealthLake 是面向医疗与生命科学行业的 FHIR（Fast Healthcare Interoperability Resources）数据存储与分析服务。它允许你以 R4 版本的 FHIR 标准组织患者健康数据，并支持通过批量导入/导出任务与 S3 进行数据交换。

在 SAP 生态中，AWS SDK for SAP ABAP 通过local client模式提供对 HealthLake API 的封装。仓库中的示例全部集中在/awsex/cl_hll_actions这个全局类中（参见 类定义与实现），其命名空间/awsex/与 SAP 命名空间定义文件 sap-abap/#awsex#.nspc.xml 对应，包描述Package for Healthlake记录在 sap-abap/services/hll/package.devc.xml 中，类元数据（描述为AWS HealthLake Code Examples，且声明WITH_UNIT_TESTS）见 sap-abap/services/hll/#awsex#cl_hll_actions.clas.xml。

所有示例方法遵循完全一致的调用骨架，后续小节将逐一展开。

前提条件

在运行任何示例之前，需要满足以下前提：

• 拥有一个 AWS 账户，并按 AWS SDK for SAP ABAP 全局配置）。
• 理解最小权限原则：建议为代码授予完成任务所需的最小权限（least privilege），不要使用管理权限运行。
• 注意费用：运行示例或测试可能会在你的 AWS 账户中产生费用，请参照 AWS Pricing 与 Free Tier 评估成本。
• 注意区域可用性：该代码未经所有 AWS 区域验证，HealthLake 并非在所有区域开放，请确认目标区域的服务可用性。

由于所有示例都硬编码了ZCODE_DEMO这个配置 Profile（CONSTANTS cv_pfl TYPE /aws1/rt_profile_id VALUE 'ZCODE_DEMO'.），你还需要在 ABAP 系统中创建一个名为ZCODE_DEMO的 AWS 连接配置（Profile），指向已配置凭据与 Region 的会话设置。

仓库代码结构

hll服务目录下包含 4 个文件：

核心编程模型：会话、工厂与客户端

从源码实现看，每个动作方法都先建立 AWS 会话，再通过工厂取得 HealthLake 客户端：

CONSTANTS cv_pfl TYPE /aws1/rt_profile_id VALUE 'ZCODE_DEMO'. DATA(lo_session) = /aws1/cl_rt_session_aws=>create( cv_pfl ). DATA(lo_hll) = /aws1/cl_hll_factory=>create( lo_session ).

• /aws1/cl_rt_session_aws=>create( )：根据 Profile 创建 AWS 运行时会话，负责凭据与区域解析。
• /aws1/cl_hll_factory=>create( lo_session )：HealthLake 服务工厂，基于会话创建类型为/aws1/if_hll的客户端接口（测试类中以TYPE REF TO /aws1/if_hll声明该引用，见测试类第 19 行）。

之后即可直接调用与 HealthLake REST API 同名的小写方法，例如createfhirdatastore、startfhirimportjob。所有调用统一包裹在TRY...CATCH中，并按操作语义捕获对应异常类型（如/aws1/cx_hllvalidationex校验异常、/aws1/cx_hllthrottlingex限流异常、/aws1/cx_hllresourcenotfoundex资源不存在异常、/aws1/cx_hllaccessdeniedex访问拒绝异常、/aws1/cx_hllinternalserverex服务器内部错误、/aws1/cx_hllconflictexception冲突异常），异常消息通过av_err_code与av_err_msg拼接输出。每个方法的文档注释（"! <p class="shorttext synchronized"...）还声明了入参、出参与RAISING /aws1/cx_rt_generic，便于在 SE24 中直接生成可用的方法签名。

FHIR 数据存储（Data Store）生命周期管理

数据存储是 HealthLake 的基础容器，对应四个动作：创建、描述、列出、删除。

创建数据存储：CreateFHIRDatastore

方法签名（源码第 13-19 行）：

METHODS create_fhir_datastore IMPORTING !iv_datastore_name TYPE /aws1/hlldatastorename EXPORTING !oo_result TYPE REF TO /aws1/cl_hllcrefhirdatastore01 RAISING /aws1/cx_rt_generic.

核心调用（源码第 201-208 行）：

" iv_datastore_name = 'MyHealthLakeDataStore' oo_result = lo_hll->createfhirdatastore( iv_datastorename = iv_datastore_name iv_datastoretypeversion = 'R4' ). MESSAGE 'Data store created successfully.' TYPE 'I'.

• iv_datastore_name：数据存储名称，类型为/aws1/hlldatastorename。
• iv_datastoretypeversion = 'R4'：FHIR 版本固定为 R4（源码中的实际写法）。
• 返回对象oo_result中可进一步取得get_datastoreid( )、get_datastorearn( )等信息——测试类的 class_setup 中正是通过这两个 getter 保存了后续所有测试所需的数据存储 ID 与 ARN。

从测试类的 class_setup 实现可以看到，真实创建数据存储是异步的：创建请求返回后，需要用wait_for_datastore_active轮询describefhirdatastore，每 60 秒检查一次状态，最多等待 40 分钟，直到状态变为ACTIVE（若出现CREATE_FAILED则断言失败）。另外测试对ThrottlingException采用了指数退避重试（15、30、60、120、240…300 秒，封顶 5 分钟），这印证了 HealthLake 对数据存储创建有较严格的限流，生产代码中建议同样实现重试逻辑。

描述数据存储：DescribeFHIRDatastore

方法签名（源码第 25-31 行），入参iv_datastore_id TYPE /aws1/hlldatastoreid，返回/aws1/cl_hlldscfhirdatastore01。核心调用（源码第 232-243 行）：

" iv_datastore_id = 'a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6' oo_result = lo_hll->describefhirdatastore( iv_datastoreid = iv_datastore_id ). DATA(lo_datastore_properties) = oo_result->get_datastoreproperties( ). IF lo_datastore_properties IS BOUND. DATA(lv_datastore_name) = lo_datastore_properties->get_datastorename( ). DATA(lv_datastore_status) = lo_datastore_properties->get_datastorestatus( ). ENDIF.

响应通过get_datastoreproperties( )取出属性对象，再读取get_datastorename( )、get_datastorestatus( )等字段。该动作是轮询数据存储状态的基石，也是测试断言（如 ID 匹配、状态为ACTIVE）最常用的验证手段。

列出数据存储：ListFHIRDatastores

无需入参（源码第 36-40 行），返回/aws1/cl_hlllstfhirdatastore01。核心调用（源码第 263-268 行）：

oo_result = lo_hll->listfhirdatastores( ). DATA(lt_datastores) = oo_result->get_datastorepropertieslist( ). DATA(lv_datastore_count) = lines( lt_datastores ). MESSAGE |Found { lv_datastore_count } data store(s).| TYPE 'I'.

响应中get_datastorepropertieslist( )返回数据存储属性对象的内表，可直接LOOP AT遍历并按get_datastoreid( )匹配目标存储。测试类list_fhir_datastores测试正是遍历该内表确认刚创建的数据存储出现在列表中且状态为ACTIVE。

删除数据存储：DeleteFHIRDatastore

方法签名（源码第 46-52 行），入参为iv_datastore_id，返回/aws1/cl_hlldelfhirdatastore01。核心调用（源码第 288-294 行）：

" iv_datastore_id = 'a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6' oo_result = lo_hll->deletefhirdatastore( iv_datastoreid = iv_datastore_id ). MESSAGE 'Data store deleted successfully.' TYPE 'I'.

删除是异步操作，删除请求返回后数据存储会进入DELETING状态。测试类的 class_teardown 中验证了这一点：调用deletefhirdatastore后检查get_datastorestatus( )是否为DELETING。注意测试注释特别提醒：HealthLake 数据存储删除耗时较长，且delete_fhir_datastore单元测试会刻意推迟到 class_teardown 执行真实删除，以免破坏其他依赖该数据存储的测试。

FHIR 导入任务（Import Job）

HealthLake 支持通过 S3 批量导入 FHIR 资源，涉及三个动作。

启动导入任务：StartFHIRImportJob

这是参数最多的动作（源码第 63-74 行）：

METHODS start_fhir_import_job IMPORTING !iv_job_name TYPE /aws1/hlljobname !iv_datastore_id TYPE /aws1/hlldatastoreid !iv_input_s3_uri TYPE /aws1/hlls3uri !iv_job_output_s3_uri TYPE /aws1/hlls3uri !iv_kms_key_id TYPE /aws1/hllencryptionkeyid !iv_data_access_role_arn TYPE /aws1/hlliamrolearn EXPORTING !oo_result TYPE REF TO /aws1/cl_hllstartfhirimpjobrsp RAISING /aws1/cx_rt_generic.

核心调用（源码第 318-338 行）：

" iv_job_name = 'MyImportJob' " iv_input_s3_uri = 's3://my-bucket/import/data.ndjson' " iv_job_output_s3_uri = 's3://my-bucket/import/output/' " iv_kms_key_id = 'arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012' " iv_data_access_role_arn = 'arn:aws:iam::123456789012:role/HealthLakeImportRole' oo_result = lo_hll->startfhirimportjob( iv_jobname = iv_job_name io_inputdataconfig = NEW /aws1/cl_hllinputdataconfig( iv_s3uri = iv_input_s3_uri ) io_joboutputdataconfig = NEW /aws1/cl_hlloutputdataconfig( io_s3configuration = NEW /aws1/cl_hlls3configuration( iv_s3uri = iv_job_output_s3_uri iv_kmskeyid = iv_kms_key_id ) ) iv_dataaccessrolearn = iv_data_access_role_arn iv_datastoreid = iv_datastore_id ). DATA(lv_job_id) = oo_result->get_jobid( ). MESSAGE |Import job started with ID { lv_job_id }.| TYPE 'I'.

参数要点：

• iv_input_s3_uri：存放待导入 FHIR/NDJSON 数据的 S3 对象 URI，对应InputDataConfig.S3Uri。
• iv_job_output_s3_uri：任务输出（如错误报告）的 S3 位置。
• iv_kms_key_id：用于加密的 KMS 密钥 ID 或 ARN。
• iv_data_access_role_arn：HealthLake 服务代为访问 S3 时扮演的 IAM 角色 ARN（信任策略主体为healthlake.amazonaws.com）。
• 返回对象get_jobid( )给出任务 ID，用于后续描述与轮询。

描述导入任务：DescribeFHIRImportJob

入参为iv_datastore_id与iv_job_id（源码第 81-88 行），返回/aws1/cl_hlldescrfhirimpjobrsp。核心调用（源码第 362-374 行）：

oo_result = lo_hll->describefhirimportjob( iv_datastoreid = iv_datastore_id iv_jobid = iv_job_id ). DATA(lo_import_job_properties) = oo_result->get_importjobproperties( ). IF lo_import_job_properties IS BOUND. DATA(lv_job_status) = lo_import_job_properties->get_jobstatus( ). MESSAGE |Import job status: { lv_job_status }.| TYPE 'I'. ENDIF.

测试类中的wait_for_job_complete展示了典型轮询模式：每 60 秒调用一次本动作读取jobstatus，最多 20 分钟，直到状态为COMPLETED或COMPLETED_WITH_ERRORS。

列出导入任务：ListFHIRImportJobs

入参为iv_datastore_id，可选iv_submitted_after TYPE /aws1/hlltimestamp（按提交时间过滤）（源码第 95-100 行）。核心调用（源码第 394-409 行）：

IF iv_submitted_after IS NOT INITIAL. oo_result = lo_hll->listfhirimportjobs( iv_datastoreid = iv_datastore_id iv_submittedafter = iv_submitted_after ). ELSE. oo_result = lo_hll->listfhirimportjobs( iv_datastoreid = iv_datastore_id ). ENDIF. DATA(lt_import_jobs) = oo_result->get_importjobpropertieslist( ).

可见时间戳参数为可选：为空时仅按数据存储 ID 列出全部任务，非空时追加时间过滤。返回的get_importjobpropertieslist( )内表每行通过get_jobid( )、get_jobstatus( )读取。

FHIR 导出任务（Export Job）

导出任务用于将数据存储中的 FHIR 资源批量导出到 S3，同样包含启动、描述、列出三个动作，模式与导入对称。

启动导出任务：StartFHIRExportJob

方法签名（源码第 112-122 行）与导入任务相比少了输入 S3 URI，核心调用（源码第 429-447 行）：

" iv_job_name = 'MyExportJob' " iv_output_s3_uri = 's3://my-bucket/export/output/' " iv_kms_key_id = 'arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012' " iv_data_access_role_arn = 'arn:aws:iam::123456789012:role/HealthLakeExportRole' oo_result = lo_hll->startfhirexportjob( iv_jobname = iv_job_name io_outputdataconfig = NEW /aws1/cl_hlloutputdataconfig( io_s3configuration = NEW /aws1/cl_hlls3configuration( iv_s3uri = iv_output_s3_uri iv_kmskeyid = iv_kms_key_id ) ) iv_dataaccessrolearn = iv_data_access_role_arn iv_datastoreid = iv_datastore_id ). DATA(lv_job_id) = oo_result->get_jobid( ).

注意导出任务的输出配置不再包一层InputDataConfig，而是直接把OutputDataConfig传给方法（SDK 方法名startfhirexportjob也不带 import 后缀）。get_jobid( )同样用于获取任务 ID。

描述导出任务：DescribeFHIRExportJob

入参iv_datastore_id与iv_job_id（源码第 129-136 行），核心调用（源码第 471-483 行）：

oo_result = lo_hll->describefhirexportjob( iv_datastoreid = iv_datastore_id iv_jobid = iv_job_id ). DATA(lo_export_job_properties) = oo_result->get_exportjobproperties( ). IF lo_export_job_properties IS BOUND. DATA(lv_job_status) = lo_export_job_properties->get_jobstatus( ). ENDIF.

与导入对应的区别仅在响应 getter 为get_exportjobproperties( )。测试中的wait_for_job_complete依据iv_job_type区分IMPORT与导出分支，分别调用 describe 导入/导出任务读取状态。

列出导出任务：ListFHIRExportJobs

入参为iv_datastore_id，可选iv_submitted_after（源码第 143-150 行），核心调用（源码第 503-518 行）与列出入库任务完全同构：

IF iv_submitted_after IS NOT INITIAL. oo_result = lo_hll->listfhirexportjobs( iv_datastoreid = iv_datastore_id iv_submittedafter = iv_submitted_after ). ELSE. oo_result = lo_hll->listfhirexportjobs( iv_datastoreid = iv_datastore_id ). ENDIF. DATA(lt_export_jobs) = oo_result->get_exportjobpropertieslist( ).

资源标签管理（Tagging）

HealthLake 资源（数据存储）支持键值对标签，用于成本分摊与资源标识。三个动作均以资源 ARN 为定位符，ARN 形如arn:aws:healthlake:us-east-1:123456789012:datastore/fhir/a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6。

添加标签：TagResource

方法签名（源码第 156-161 行），核心调用（源码第 538-545 行）：

lo_hll->tagresource( iv_resourcearn = iv_resource_arn it_tags = it_tags ). MESSAGE 'Resource tagged successfully.' TYPE 'I'.

it_tags的类型是/aws1/cl_hlltag=>tt_taglist（标签对象内表）。测试中通过NEW /aws1/cl_hlltag( iv_key = ... iv_value = ... )构造标签并 APPEND 到内表，一次可添加多个标签。本动作无返回对象，成功即不抛异常。

列出标签：ListTagsForResource

方法签名（源码第 167-173 行），核心调用（源码第 565-573 行）：

DATA(lo_result) = lo_hll->listtagsforresource( iv_resourcearn = iv_resource_arn ). ot_tags = lo_result->get_tags( ). DATA(lv_tag_count) = lines( ot_tags ). MESSAGE |Found { lv_tag_count } tag(s).| TYPE 'I'.

响应通过get_tags( )取出tt_taglist内表；遍历时用get_key( )/get_value( )读取每个标签的键值。测试类list_tags_for_resource测试正是遍历标签确认 class_setup 中添加的convert_test=true标签确实存在。

移除标签：UntagResource

方法签名（源码第 179-184 行），与 Tag 动作的差异在于入参为标签键列表it_tag_keys TYPE /aws1/cl_hlltagkeylist_w=>tt_tagkeylist。核心调用（源码第 593-600 行）：

lo_hll->untagresource( iv_resourcearn = iv_resource_arn it_tagkeys = it_tag_keys ). MESSAGE 'Resource untagged successfully.' TYPE 'I'.

测试类中完整的"添加 → 验证存在 → 移除 → 验证消失"流程，可作为标签管理闭环的参考实现。

运行示例：通过 SE24 调用

按照 sap-abap 目录 README 的说明，每个示例都可以在 SAP 系统的事务代码 SE24（Class Builder）中直接执行：

1. 用 SE24 打开全局类/AWSEX/CL_HLL_ACTIONS（确认对象已通过 abapGit 导入，元数据见 类 XML）。
2. 在"方法"列表中选中某个动作方法（如CREATE_FHIR_DATASTORE），进入测试/执行视图。
3. 为方法的 IMPORTING 参数填入实际值（方法注释中均给出了示例值，如数据存储名称、S3 URI、角色 ARN 等）。
4. 执行方法，观察信息消息（TYPE 'I'）中的成功提示或异常消息。

各动作在实现文件中的精确位置（与 README 中行号索引一致）汇总如下：

运行测试

仓库为这些示例提供了完整的 ABAP 单元测试，详见 测试类实现。测试类ltc_awsex_cl_hll_actions声明为FOR TESTING DURATION LONG RISK LEVEL DANGEROUS，意味着：

• 会产生真实 AWS 费用：运行测试前请确认使用合适的测试 AWS 账户（见 sap-abap README 的 Important 说明）。
• 测试会真实创建并删除 AWS 资源，包括：S3 导入/导出桶、IAM 角色及策略、KMS 密钥、HealthLake 数据存储。

测试基础设施（class_setup）展示了完整的端到端准备工作，可作为生产集成的参考蓝图：

1. 创建命名形如sap-hll-import-{account}-{uuid}与sap-hll-export-{account}-{uuid}的 S3 桶，并写入一条示例 FHIR 数据（{"resourceType":"Patient","id":"example",...}形式的 NDJSON）。
2. 创建信任主体为healthlake.amazonaws.com的 IAM 角色，并附加内联策略HLLAccessPolicy，授权范围覆盖导入/导出桶的 S3 操作、KMS 加解密（kms:Decrypt、kms:GenerateDataKey、kms:DescribeKey、kms:CreateGrant）以及healthlake:*。
3. 创建用于加密的 KMS 密钥，其密钥策略显式允许 HealthLake 服务主体使用。
4. 创建唯一的 HealthLake 数据存储（名称形如SAPDS{uuid}），随后将数据存储 ARN 写入角色信任策略的aws:SourceArn条件，收紧跨服务访问权限。

全部资源均打上convert_test=true标签用于统一清理；class_teardown 则负责删除数据存储、IAM 角色与策略，并为 KMS 密钥调度 7 天后删除。

测试覆盖了全部 13 个动作的调用与断言，其中值得注意的几点：

• create_fhir_datastore测试断言数据存储 ID 与 ARN 非空、状态为ACTIVE，并通过 describe 反向验证。
• list_fhir_datastores测试遍历列表确认新创建的数据存储出现在结果中。
• 标签测试执行完整的"添加标签 → 列出验证 → 移除标签 → 确认消失"闭环。
• 导入/导出任务测试验证启动后返回的 Job ID 与状态非空，describe 返回的属性对象与 Job ID 匹配。
• delete_fhir_datastore测试刻意把真实删除推迟到 class_teardown，避免破坏其他依赖数据存储的测试，印证了数据存储是共享资源、删除操作应谨慎编排。

附加资源

• HealthLake Developer Guide
• HealthLake API Reference
• SDK for SAP ABAP HealthLake reference
• 仓库中的相关目录：sap-abap/services/hll、sap-abap 目录 README

Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.

SPDX-License-Identifier: Apache-2.0

• 示例工程
• 教程
• 后端