ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

使用 AWS SDK for SAP ABAP 操作 AWS HealthLake:FHIR 数据存储与导入导出任务实战

使用 AWS SDK for SAP ABAP 操作 AWS HealthLake:FHIR 数据存储与导入导出任务实战 示例工程教程后端【免费下载链接】aws-doc-sdk-examplesWelcome to the AWS Code Examples Repository. This repo contains code examples used in the AWS documentation, AWS SDK Developer Guides, and more. For more information, see the Readme.md file below.项目地址https://gitcode.com/gh_mirrors/aw/aws-doc-sdk-examples点击查看免费下载本文以 aws-doc-sdk-examples 仓库中 sap-abap/services/hll/README.md 为核心讲解如何在 SAP ABAP 环境中通过 AWS SDK for SAP ABAP 调用 AWS HealthLake 的全部 13 个单动作 APIFHIR 数据存储Data Store的创建、描述、列出与删除FHIR 导入/导出任务的启动、描述与列出以及资源的标签管理。读完本文你将掌握 HealthLake 在 ABAP 侧的完整编程模型会话创建 → 服务工厂 → 方法调用 → 异常处理了解每个动作的入参类型、响应对象结构并能通过 SE24 调用示例方法或在 ABAP 单元测试中验证全链路行为。概览HealthLake 与 SAP ABAP 的集成方式AWS HealthLake 是面向医疗与生命科学行业的 FHIRFast 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这个配置 ProfileCONSTANTS cv_pfl TYPE /aws1/rt_profile_id VALUE ZCODE_DEMO.你还需要在 ABAP 系统中创建一个名为ZCODE_DEMO的 AWS 连接配置Profile指向已配置凭据与 Region 的会话设置。仓库代码结构hll服务目录下包含 4 个文件文件作用sap-abap/services/hll/README.md服务级说明文档列出全部单动作示例及行号索引sap-abap/services/hll/#awsex#cl_hll_actions.clas.abap核心实现类含 13 个动作方法的定义与实现sap-abap/services/hll/#awsex#cl_hll_actions.clas.testclasses.abapABAP 单元测试类DANGEROUS 级别会真实创建/删除 AWS 资源sap-abap/services/hll/#awsex#cl_hll_actions.clas.xmlabapGit 序列化的类元数据核心编程模型会话、工厂与客户端从源码实现看每个动作方法都先建立 AWS 会话再通过工厂取得 HealthLake 客户端CONSTANTS cv_pfl TYPE /aws1/rt_profile_id VALUE ZCODE_DEMO. DATA(lo_session) /aws1/cl_rt_session_awscreate( cv_pfl ). DATA(lo_hll) /aws1/cl_hll_factorycreate( lo_session )./aws1/cl_rt_session_awscreate( )根据 Profile 创建 AWS 运行时会话负责凭据与区域解析。/aws1/cl_hll_factorycreate( 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 classshorttext 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 R4FHIR 版本固定为 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 JobHealthLake 支持通过 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_arnHealthLake 服务代为访问 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( ).资源标签管理TaggingHealthLake 资源数据存储支持键值对标签用于成本分摊与资源标识。三个动作均以资源 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_hlltagtt_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_testtrue标签确实存在。移除标签UntagResource方法签名源码第 179-184 行与 Tag 动作的差异在于入参为标签键列表it_tag_keys TYPE /aws1/cl_hlltagkeylist_wtt_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 系统的事务代码 SE24Class Builder中直接执行用 SE24 打开全局类/AWSEX/CL_HLL_ACTIONS确认对象已通过 abapGit 导入元数据见 类 XML。在方法列表中选中某个动作方法如CREATE_FHIR_DATASTORE进入测试/执行视图。为方法的 IMPORTING 参数填入实际值方法注释中均给出了示例值如数据存储名称、S3 URI、角色 ARN 等。执行方法观察信息消息TYPE I中的成功提示或异常消息。各动作在实现文件中的精确位置与 README 中行号索引一致汇总如下动作实现行号CreateFHIRDatastoreL201DescribeFHIRDatastoreL232ListFHIRDatastoresL263DeleteFHIRDatastoreL288StartFHIRImportJobL318DescribeFHIRImportJobL362ListFHIRImportJobsL394StartFHIRExportJobL429DescribeFHIRExportJobL471ListFHIRExportJobsL503TagResourceL538ListTagsForResourceL565UntagResourceL593运行测试仓库为这些示例提供了完整的 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展示了完整的端到端准备工作可作为生产集成的参考蓝图创建命名形如sap-hll-import-{account}-{uuid}与sap-hll-export-{account}-{uuid}的 S3 桶并写入一条示例 FHIR 数据{resourceType:Patient,id:example,...}形式的 NDJSON。创建信任主体为healthlake.amazonaws.com的 IAM 角色并附加内联策略HLLAccessPolicy授权范围覆盖导入/导出桶的 S3 操作、KMS 加解密kms:Decrypt、kms:GenerateDataKey、kms:DescribeKey、kms:CreateGrant以及healthlake:*。创建用于加密的 KMS 密钥其密钥策略显式允许 HealthLake 服务主体使用。创建唯一的 HealthLake 数据存储名称形如SAPDS{uuid}随后将数据存储 ARN 写入角色信任策略的aws:SourceArn条件收紧跨服务访问权限。全部资源均打上convert_testtrue标签用于统一清理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 GuideHealthLake API ReferenceSDK for SAP ABAP HealthLake reference仓库中的相关目录sap-abap/services/hll、sap-abap 目录 READMECopyright Amazon.com, Inc. or its affiliates. All Rights Reserved.SPDX-License-Identifier: Apache-2.0赞分享示例工程教程后端【免费下载链接】aws-doc-sdk-examplesWelcome to the AWS Code Examples Repository. This repo contains code examples used in the AWS documentation, AWS SDK Developer Guides, and more. For more information, see the Readme.md file below.项目地址https://gitcode.com/gh_mirrors/aw/aws-doc-sdk-examples点击查看免费下载相关推荐使用 Boto3 管理 AWS HealthLakeFHIR 数据存储与导入导出作业实战指南aws-doc-sdk-examples使用 Boto3 管理 AWS HealthLakeFHIR 数据存储与导入导出作业实战指南aws doc sdk examples 导读 本文以 aws示例工程教程后端Infisical MFA 双重验证完整配置指南3 种方式对照Infisical MFA 双重验证完整配置指南3 种方式对照 Infisical 是自托管的密钥、证书与特权访问管理平台密钥库里存的是生产凭据一旦账号密示例工程教程后端使用 AWS SDK for SAP ABAP 操作 Amazon Kinesis数据流实战指南使用 AWS SDK for SAP ABAP 操作 Amazon Kinesis数据流实战指南 导读 本文基于 sap abab/services/kns/示例工程教程后端上一篇nds-bootstrap完整指南在3DS上原生运行NDS游戏的终极解决方案下一篇Qwen2.5-3B量化优化指南8位量化技术让模型推理速度提升3倍的秘诀创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表