この記事は2022年SAPアドベントカレンダーの12/25分の記事として執筆しています。
Roadmap to become SAP BTP Developer – “Developer is the KING”に着想を得て改訂、日本のSAPコミュニティ向けに執筆したものです。
Roadmap to become a "SAP BTP Consultant"
はじめに
この記事の中でSAP Business Technology Platform(BTP)について語り始める前に、私のことと、このロードマップの位置付けについて書かせてください。
私は過去6年程このSAP業界でお仕事をしており、特にここ数年はBTPについてのお仕事をする機会を多く頂いております。
私がBTPを触り始めたのは、その製品名がSAP Cloud Platform(SAP CP)と呼ばれており、丁度Cloud Foundry(後述)が旧来のNeoに代わって登場し始めた頃でした。当時は今ほどのサービスの選択肢や、情報が多くはなくそれなりに苦労をしながら手探りで最適解を見出していくようなことをしていました。
あれから月日は経ち、今では私の身の回りの社内・社外問わず本当に多くの方々がBTPを利用し、比例してたくさんの情報やサービスそのものが整いつつあることを実感しています。
ロードマップ作成の意図
ですが、それと共に増え続ける私への1つの質問があります。それは、
BTPにサービスがたくさんあるのはわかりました。で、何からやればいいんですか? と。
これに答えるのは、BTPを熟知している方でも難しいのではないでしょうか。(むしろ熟知しているからこそかも)
もちろんSAPには資格試験も充実しており、それらに取り組むことで網羅的に知識を身につけることは可能でしょう。
ですが私は、それよりもより体系的にBTP全体の指針を示しながらスキルを高めていけることを標榜し、このロードマップを作成するに至りました。
ロードマップは上から順番にBTPにおいて重要ではないかと考えられる順序で記載しているつもりです。順番に辿れば理解はより深まることと考えています。
この記事が学習者のロードマップとなることと同時に、日々アップデートされていくBTPサービスにキャッチアップしていく1つのきっかけになればと思います。
SAPコミュニティへのおねがい
ここで一つ注意点です。
このロードマップは未完成です。
確かに私は数年に渡ってBTPに携わってきました。ですが決して全てのBTPサービスを完全にマスターしているというわけではありません。
そしてSAPコミュニティには、各サービスにおいてスペシャリストと呼べるような方々がたくさんいらっしゃいます。
ぜひこのロードマップにコミュニティのみなさんの声を反映させながら”最適解”に近づけていければと思ってます。
「このサービスについて取り組むべきではないか」、「これは誤った導入ではないか」といった声をぜひコメントやTwitterでぶつけて頂けると嬉しいです。
最終的にはSAPコミュニティとしてのアセットと言えるようなものになれば喜びもひとしおです。
あえてタイトルを開発者ではなくコンサルタントとしているのは、様々なロールの方の目線からも最適なものに近づけていけるようにという思いからです。
どちらかというと開発寄りの技術仔細にフォーカスするというより、大分類としてどういうサービスの切り分けができるのか、そこから何に繋げていけばいいのかということに主軸をおいています。
Runtime Environment
Cloud Foundry(CF)
CFが分かればほとんどBTPを理解したということ、と言っても過言ではないでしょう。
アプリケーション開発の起点,基盤であり、BTPで提供されるサービスの多くはCFに関連しています。
BTPのアプリケーションはインフラ層の構成を考慮することが不要であり、CFが良しなにアプリケーションごとに実行環境のコンテナを用意してくれることで成り立っているということが分かれば良いでしょう。
また、CFに関してはSAPの独自技術ではなくOSS(Open Source Software)であるため、検索エンジンで何か調べる際はBTPではないOSSとしてのCFについての記事も多くヒットすることを覚えておきましょう。
コンテナについてはそれだけで1冊本が書けてしまうほど盛りだくさんなので、まずは下記記事から概要を掴むのがおすすめです。
Kyma Runtime
"普通"のアプリケーションの実行環境がCFであるならば、特定の用途に合わせて使うのがKymaです。
Kymaは大きく2種類あり、アプリケーションのスケーラビリティを強化した環境であるKubernetes Runtimeと、サーバの管理を完全に不要として必要な時にだけ動作をするServerless Runtimeがあります。
Kubernetesについては過去に拙著にまとめたのでそちらをご覧ください。
ABAP Runtime
ABAPといえば通常はS/4HANAなどのERP上で開発,実行が可能な言語ですが、こちらはBTPでもABAPの開発,実行を可能とした環境です。
特にS/4HANA上でABAPカスタム開発が出来なかったS/4HANA Essential EditionにおいてもABAPでのカスタム開発を実現可能なツールとして注目を集めました。
ただし全てのABAP命令を使用できるわけではない点や、近年はCloud版のS/4HANAでもABAP開発ができるEmbedded Steampunkの登場によって用途は限定的となってきている印象です。
Embedded Steampunkと並んでABAP開発者にとっては重要なサービスですが、その使い分けについては今後も検討が必要なポイントです。
こちらにまとまっているのでぜひご一読ください。
Application Development
Business Application Studio(BAS)
詳細は後述しますが、BTPにはService Instanceという開発アプリケーションのサポートをする役割を持った/あるいはアプリケーションとして独立した機能を持った、SAPマネージドサービスがあります。
こちらのBASもそのサービスの一部ではありますが、最もよく使用されるサービスの一つであるため優先的にピックアップしました。
BASが提供しているのはアプリケーションの開発環境(IDE)です。
Eclipse Theiaをベースとしつつ、VSCodeライクな見た目が特徴的なサービスで、このサービスがあることによって1つのブラウザで開発が完結させることが可能です。
つまり、開発者のそれぞれのローカル環境に依存することなく開発ができることが大きなメリットです。
こちらは少し古いですが、基本を抑えるには必要十分な情報が記載されています。
Multi Target Application(MTA)
MTAは端的に言うなればBTPのアプリケーションプログラムのまとめ役です。
CFに合わせて開発されたSAPの独自技術であり、後述するFiori(SAPUI5)やバックエンドのプログラムをまとめて1つの移送単位として管理することができます。
CFではアプリケーションのインフラ層の考慮が不要と記載しましたが、それもMTAがアプリケーションに必要な設定を裏で実行してくれていることに由来しています。
その設定は簡易的にMTAに含まれるmta.yamlにて調整することが可能です。アプリケーション開発者にとっては、mta.yamlの内容を理解することが後述するService Instanceを活用しながら開発を進めるキーポイントになってきます。
またMTAアプリケーションを強力にサポートするライブラリとツールを包含したフレームワークとしてCAP(SAP Cloud Application Programming Model)も開発には必須技術となりつつあります。
CAPを使うことで、DBレイヤーのデータモデルおよびUIを各プログラム言語ではなくCDS(Core Data Services)で記述することが可能であり、よりシンプルな開発を実現しています。
まずは最小構成のMTA開発から始めていくことをおすすめしています。
Fiori, SAPUI5
ここからは上述したMTA内で開発/実行される個別のアプリケーションについて、まずはフロントエンドからです。
FioriについてはBTPのみならず、S/4HANAにも用いられる技術(というよりは単なるデザインコンセプトを指す言葉であることが多い)ですが、BTPのアプリケーションとしてフロントエンド, UIを実装する場合にもFioriを選択することが多いかと思います。
そのFioriはSAPUI5によって実現されています。
SAPUI5はJavaScript, CSS, HTMLといったUIを構成する一般的なプログラム言語をベースにした、SAPの独自UIフレームワークです。
前述のBASを利用し、SAPUI5によってFioriアプリケーションを作るチュートリアルは数多く存在しますが、代表的なものを以下に貼り付けておきます。
Node.js, Java
フロントエンドであるUIを実現するのがSAPUI5であれば、バックエンドの仕組みを実現するプログラム言語もあります。
BTPにおいてはNode.js(サーバサイドJavaScript)あるいはJava辺りが有力な選択肢になります。
BTPでは"疎結合化"というものが一つのキーワードであり、アプリケーションについてもそれぞれのレイヤーで役割を分担・分割することが主流です。これは処理の効率化であったり、それぞれの部品を再利用可能なものにすることが目的であったりします。
フロントエンドから分離されたバックエンドではフロントエンドから受けたデータ処理や他サービス/ソリューションとの連携を担うことが多いでしょうか。
これも数多くのチュートリアルがありますが、一つ選んでリンクを書いておきます。
HDI
上述の通り、BTPアプリケーションは役割ごとにレイヤーが"疎結合化"している(ことが望ましい)のですが、DBオブジェクト、データ処理に関連したレイヤーを担うのがHDI(HANA Deployment Infrastructure)です。
HDIはその名にHANAと付いている通り、特にHANAにDBオブジェクトやDBアプリケーションをデプロイするための仕組みです。
MTAのアプリケーションはHDIを介してHANAとデータのやり取りをすることが基本というイメージが持てればよいです。
HDIについて理解するためには、後述するHANA Cloudについても理解しなければならないですが、順番としてはまずはHANA Cloudに触れてからHDIという流れがよいかもしれません。
HANA Cloud
S/4HANAにも実装されている、インメモリデータベースであるHANAをBTP上で実現させたものがHANA Cloudです。(S/4HANA Cloudとは違うので要注意)
基本的な機能としてはS/4HANAに実装されているHANAと同等ですが、特にBTPアプリケーションとHANA Cloudを連係させるためには上記HDIと合わせて理解をする必要があります。
まずは基本的な動作を下記記事を基に習得するのをおすすめします。若干古いため現在とUIが多少異なる部分がありますが、日本語で書かれており今でも非常に有用です。
SAP Cloud SDK
BTPアプリケーションの開発を強力にサポートするのがCloud SDKです。Java版とJavaScript版が存在します。
狭義にはプログラムのライブラリ(例)を指してSDKと呼ぶことが多いイメージですが、実際には後述するDestinationやXSUAAなどのサービスも含めた広義的な方が正しい内容のようです。
いずれの場合も、S/4HANAなどのSAPソリューションとBTPアプリケーションを繋ぐ部分の処理をSAP提供のこのSDKを使うことでより簡単に、セキュアに実装可能とすることが目的です。
SDKを利用できること≒(アプリケーション実行環境として)BTPを利用する大きなメリット であり、他のクラウド基盤では得られない恩恵でもあると言えます。
およそ2週間に一度という高頻度で最新版の提供が繰り返されています。
OData
ODataは厳密にはBTPの技術というわけではなく主にS/4HANAに関連した技術ですが、BTPを利用する上でS/4HANAとの連携は切っても切れないものであり、ODataについての知識は多くの場面で必要とされるため取り上げました。
BTPを始めとした多くのWeb上で動くアプリケーションはRestful APIというプロトコルをベースにして通信連携をしていますが、ODataはそのプロトコルに対応したS/4HANAのインターフェースです。
(厳密にはRestはプロトコルではありませんが簡単のためプロトコルと説明しておきます)
ODataを介することでBTPのアプリケーションはS/4HANAとデータのやり取りを交わすことが可能となります。
ビジネスロジックをS/4HANAではなくBTP上に実現することでS/4HANAのコアをクリーンに保つ、というアーキテクチャを実現する大きな立役者となっているものの一つがこのODataであったりします。
コアクリーンの考え方についてはWhy BTP?という問題を解く大きなテーマですが、これも記事が1つ書けてしまうほどの膨大なテーマなので割愛し、簡単に説明された記事を紹介します。
SCC(SAP Cloud Connector)
こちらもBTPのサービスではありませんが、BTPアプリケーションと他ソリューション(特にオンプレ製品)を繋ぐために必要なサービスです。
BTPからSCCを介した通信は全て、SCCが作ったセキュアトンネルを通ることとなります。
セキュリティ面の担保を強化することが大きな目的ですが、通信の制限などの管理もSCCにて行うことが可能です。
繰り返しですがBTPの付帯サービスではないので、SCCの提供形態についてはそれぞれの環境ごとに確認が必要です。
Service Instances 1
前述の通り、SAPにはService Instanceというマネージドサービスがありますが、この章ではこれまで紹介してきたBTPのアプリケーションを強力にサポートする特性を持ったマネージドサービスをピックアップして紹介します。
Destination
SDKでも紹介した、BTPアプリケーションをサポートするサービスの代表格です。
その中身としては、BTPアプリケーションで利用するS/4HANAのインスタンスURLや、連携先他ソリューションのURLといった"宛先"を、Key-Valueの形式で保存することができるサービスとなっています。
BTPアプリケーションからはDestinationに保存したKey情報を呼び出すだけで、予めDestinationに保存しておいた宛先のURLだけではなく、S/4HANAのクライアント番号やアクセス先の認証方式の指定方法、ユーザのクレデンシャル情報などを利用することが可能です。
ある意味ではDestinationサービスによって"宛先"情報をアプリケーションから"疎結合化"することを実現しているとも考えられます。
Destinationそのものは単なるKey-Valueストアのようなサービスなのでこれ自体のチュートリアルなどはありませんが、数多くのチュートリアルの中で登場します。
XSUAA(Authorization & Trust Management)
こちらも広義ではSDKの一部であり、BTPアプリケーションの認証認可、権限割当を行うサービスです。
ユーザがBTPアプリケーションにアクセスする際には、UIからXSUAAを介して認証を実施しており、アクセスしたユーザ情報をバックエンドやS/4HANAへ伝播させる役割も果たしています。
後述するLaunchpadのアプリケーションアクセス権限の制御の役割も果たしており、BTPアプリケーションの認証認可には不可欠なサービスとなっています。
https://blogs.sap.com/2022/08/26/sap-btp-security-how-to-handle-authorization-and-attributes-2-with-xsuaa-and-ias/
CF Runtime
厳密にはService Instanceとは異なるのですが、CF環境のBTPアプリケーションを考える上で重要な概念なので入れました。
CFのBTPアプリケーションは各コンテナ上で実行されると書きましたが、その際にCF Runtimeというランタイムメモリを使用して動きます。
メモリの割り当て量は前述のmta.yamlにて決定され、CF環境全体で使用可能なCF Runtimeを後述のQuota Planにて制御しています。
アプリケーションの本数に合わせてCF環境全体のCF Runtimeの数量をコントロールしていくことがBTP活用のカギとなります。
Service Instances 2
ここからはService Instance 1の章とは異なり、それぞれのサービス自体が単体のアプリケーションとして動作しながら、連携/拡張を実現する類のマネージドサービスです。
Launchpad
前述のFioriをベースとしつつ、アプリケーション群をタイルとして配置したエントリポイントサービスです。
https://experience.sap.com/fiori-design-web/launchpad/
BTPではS/4HANAのようにトランザクションコードがあるわけではないので、ユーザはこのLaunchpadからアプリケーションへアクセスすることが一般的な流れになります。
これはFioriの基本思想でもありますが、Launchpadに並べられるコンテンツは業務ロールベースで整理され、それぞれのロールが割り当てられたユーザごとに、関連した業務アプリケーションへアクセスするタイルを配置することができます。
ページのレイアウト構成はFioriデザインベースですがある程度カスタマイズ変更設定も可能で、アプリケーションの利用頻度をタイルの配置順に反映するなどより操作しやすいエントリポイントを作ることできます。
LaunchpadはBTPだけではなくS/4HANAでも提供されていますが、同様に検索、通知などの機能が備えられています。
Integration Suite
名前の通り、SAPソリューションの統合を実現するサービスです。しかし統合できるのはSAPソリューション同士に限らず、それ以外のソリューションとの連携も可能です。
Integration Suiteの中では、Cloud Integration, Open Connectors, API Managementの3つのサービスが同居しています。
始めのCloud Integrationがメインと言っても過言ではない、BTPとS/4HANAをはじめとしたSAPソリューション間での連携処理を提供しています。
連携処理はあらかじめ事前定義されたいくつかのシナリオが用意されており、シナリオを利用することで最低限のカスタマイズ設定のみで連携を実現することができます。シナリオの通信プロトコルにはIDocやSFTP、SOAP、OData(Rest)など様々な方式が用意されているため、複雑な処理の実装を必要としないことが特徴です。シナリオを用いて処理を実装すること自体も可能です。
Open ConnectorsはCloud IntegrationにはないようなTwitterやSlack, Teamsといった160種類以上のサービスとの接続ツールを提供しているサービスです。
特にSFDCやAWSとの連携も用意されているため、この辺りがビジネス要件としては活用ポイントになってくるかと思います。
https://discovery-center.cloud.sap/missiondetail/3097/3117/
最後にAPI Managementは、Cloud IntegrationやBTPアプリケーションなどのAPIのアクセスを一元管理する機能です。アクセス通信のIP制限などをかけることにより、よりセキュアな機能を通信を実装することが可能となっています。
BTPのアプリケーションがExtensionの代表であるのに対し、Integration Suiteは名前の通りIntegrationでの代表選手です。
場面に応じて利用頻度が高く登場するサービスであるため、ぜひ中身まで抑えておきたいところです。
最初のチュートリアルとしては以下が良いでしょう。
Event Mesh
旧Enterprise Messagingと呼ばれていたサービスの新名称, 進化版で、SAPソリューションやそれ以外のアプリケーションと非同期でメッセージ連携を行うためのサービスです。
勘の良い方であればお気づきかもしれませんが、今まで難しかったS/4HANA→BTPという順番での連携を実現可能としているのがこのEvent Meshです。
https://blogs.sap.com/2021/08/11/enable-your-business-to-operate-in-real-time-with-sap-event-mesh-of-sap-business-technology-platform/
BTPには後述するJob Schedulerなどがあるため、BTPから処理を呼び出してS/4HANAへ連携する、というシナリオを組むことは容易ですが、S/4HANAから処理をキックしてBTPへ連携することは容易ではありませんでした。
それをEvent Meshを利用することで伝票作成のイベントをトリガーにしてメッセージを連携し、処理を開始するといったシナリオが実現できるようになりました。
下記ブログにてかなり詳しく解説&簡単なセットアップからチュートリアルまでを兼ねているので参考にしてください。
Workflow Management
2023年にサービス単体としては消滅し、新たにSAP Build Process Automationという統合サービスに組み込まれる予定となっています。
Workflow Managementはユーザの承認を伴うビジネスプロセスの実装や、複数ソリューションを連携させてプロセスを進行させる、といったことを実現することに特化したサービスです。
Workflow Managementにも前述のCloud Integrationと同様に事前定義されたシナリオが用意されており、これらはカスタマイズ設定のみで使うことが可能です。
ワークフローエディターを使ってフローを定義することにより、定義済シナリオにはない自由度の高いワークフローを構築することも可能です。
https://blogs.sap.com/2022/04/02/my-learning-journal-on-btp-series-3-sap-cloud-platform-workflow-and-abap-restufl-programming-model-rap/
iRPA(Intelligent Robotic Process Automation)
こちらもWorkflow Managementと同様にSAP Build Process Automationという統合サービスに組み込まれる予定となっています。
iRPAも例に漏れず名前の通りBTP用のRPAサービスです。
特にサービスとしてProcess Automationに組み込まれていることからもわかる通り、Workflowなどのビジネスプロセスの自動化実現をするためのツールになっています。
よく見かけたチュートリアルはこちらでした。
AppGyver
こちらもまたSAP Build Process Automationに組み込まれる予定のサービスです。
つまり、勘の良い方は気づいたかもしれませんが、こちらもビジネスプロセスの自動化を実現するためのサービスの一員です。
端的には、巷で流行の兆しを見せているLow Code/No Code(LC/NC)ツールのBTP版サービスです。
その名の通りプログラム実装を全くしない/あるいは少なくしてアプリケーションを開発できるツールということです。特定のプログラミング言語のスキルがない場合も、GUIの操作で簡単にアプリケーションを作ることができます。
Workflowなどもある意味ではLC/NCツールですが、AppGyverはより自由度の高いアプリケーションの開発に向いているという特性があります。
私は下記のプロト作成記事が好きです。
Work Zone
こちらもまたまたSAP Buildの一種です。
言うなれば、強化版Launchpadと形容するのが簡単でしょうか。
Launchpadサービスで提供されているのは従来からよく見られてきたFioriデザインのエントリポイントサイトでした。
Work Zoneではさらにその枠を超えて、単にアプリケーションへアクセスするためのエントリとしての機能だけではなく、下記のような様々な情報を提示するようにカスタマイズが可能となったサービスとなっています。
ビジネスKPIやS/4HANAを通じた在庫状況など細かな情報をこのエントリポイントに集約可能とすることで、従来は叶わなかったUIの実現を可能とした、より自由度の高いサービスです。
https://blogs.sap.com/2021/12/07/what-is-sap-work-zone/
Application Logging
BTPのアプリケーションログを見るときには、基本は単なるテキストとしてしか提供はされませんが、このサービスを通すことでグラフィカルなログ分析が可能となります。
ただしこのサービス自体で行えるのはあくまで分析のみとなるため、ログ監視などを実施する場合は次項Alert Notificationサービスを組み合わせる必要があります。
https://discovery-center.cloud.sap/serviceCatalog/application-logging
Alert Notification
BTPサービスのエラー、警告を検知して通知を送るサービスです。
CFアプリケーションのエラーや、Cloud IntegrationなどのService Instanceなどとも組み合わせて利用することが可能です。
DevOps
(個人的には)近年最も熱い分野の一つです。
他のサービスがビジネスユーザ体験そのものを直接支えるようなサービスであるのに対し、DevOps系のサービスは開発者体験を支えるものとなっています。
しかし開発者体験の向上は、間接的にはビジネスユーザ体験の向上に繋がることは何となくご理解頂けるかと思います。
これまで拙著にてDevOpsサービスの素晴らしさについて書き連ねてきたのでここで多くは語りませんが、アプリケーションのビルドから単体テスト/移送まで全てのプロセスがBTPサービスで自動化できるようになりつつあります。
それを支えるのがコードチェックやテストコードの実行を可能としたContinuous Integration & Deliveryであったり、移送管理/自動化を行うCloud Transport Management、単体テストの自動化を実現したAutomation Pilotといったツールです。
内容はともあれまずはこちらをぜひご一読ください。
Git
こちらはBTPサービスではなくOSS開発において広く登場する一般的な技術ですが、DevOpsの利用有無に限らず抑えておくべき分野であるため入れました。
誤解を恐れずに端的に言うなれば、プログラムソースコード版のMS SharePointのようなものです。(もちろん厳密には違います)
Gitを利用することでプログラムソースコードのバージョン管理を実現することができます。
また複数人の開発者でGitリポジトリを共有することができるため、管理された仕組みの中でバージョンコントロールを行いながら開発を進めることを可能としています。
残念ながらBTPにはGitサービスは存在しないため(厳密には旧Neoにはありますが旧サービスであるため割愛)、Gitリポジトリサービスとして代表的なGithubやGitlab, BitbucketなどとBTPを連動させながら利用する必要があります。
どのサービスも基本的な提供機能はベースのGit自体に沿っているためほとんど変わりません。
まずはGit自体の仕組みについて抑えておくのをおすすめします。
Postman
こちらもBTPサービスではなくOSS開発に広く登場するサービスの一つです。
前述したDevOpsツールを用いてプログラムテストを全自動で実施できるようにしておくことが理想的ではありますが、それで全てを補えない場面も出てくることはしばしばあります。
そこでこのPostmanを利用することで、Restful APIのテスト実行を手動で実行することが可能となります。
Restful APIの実行時にはHTTPのメソッドやリクエストボディ項目、認証方式と認証情報など、条件を組み合わせて正しく実行する必要がありますが、これらをプログラムで実装するのではなくツールの項目入力で実現することで、非開発者でも簡単にAPIの実行ができます。
PostgreSQL
BTPは当然SAPのソリューションですが、その中で利用できるDBはHANAだけではありません。
代表的なものがこのPostgreSQLです。
HANAと同様にRDBMSベースのサービスですが、インメモリDBではないので高速化を必要としないようなDBを検討する際に選択肢に入るサービスとなります。
ユースケースは多くはないですが、DBの選択肢として知っておくべきサービスの一つです。
Job Scheduling Service
ジョブのスケジューリングを行うことがメインのサービスです。
ジョブと言っているのはBTP CF上のカスタムアプリケーションを指しています。
特にUIを持たないアプリケーションはジョブとしてスケジュール通りに動くことが多いため、このJob Scheduling serviceを利用することで、バッチ処理などの時刻をトリガーとして一連のプロセスを実行することができます。
前述のPostmanを使えば手動での実行は可能ですが、スケジューリングが可能であるため業務要件に沿った実行を実現することが可能となります。
Document Management Service
BTPのアプリケーション上でExcel文書ファイルや画像データ、PDFファイルをやり取りする必要がある場面というものが時々求められます。
その時に使用するのがDocument Management Serviceです。
Identity Authentication
BTPにアクセスする際の認証プロバイダーは通常はSAP社の認証プロバイダー(SAP Universal ID)ですが、ビジネス要件に応じて認証プロバイダーを変更したい要件が出ることがあります。
Identity Providerを利用することで認証プロバイダーを切り替えるだけではなく、ユーザ毎の権限設定などを実現することが可能です。
Forms Service by Adobe
AdobeのADS(Adobe Document Service)コンポーネントをベースとしたBTP版のクラウド帳票サービスです。
紙文書の帳票と同じような帳票を作成することができ、S/4HANAやBTPなどに含まれるデータから動的なPDF文書を生成することが可能です。
Mobile Service
Mobile Serviceはその名の通りモバイルアプリの開発や設定、管理をすることができるサービスです。
SAP BTP SDK for iOSという、Swiftベースのフレームワークと開発ツールを提供しているため、CFアプリケーションの開発と同様に認証や OData 呼び出しなどの主要な機能をSDKでサポートしていることが利用メリットです。開発プロジェクトの雛形のようなものも提供していることから、比較的簡単かつFioriライクなモバイルUIを開発可能となっています。(Android版もあり)
謝辞
下記の方々が寄稿していたブログ記事を引用させて頂きましたのでこの場で御礼申し上げます。
https://people.sap.com/minok104
https://people.sap.com/r_asai
https://people.sap.com/kimikazu.kabata
https://people.sap.com/saptechengineer
https://people.sap.com/carlos.roggan
https://people.sap.com/kyoneo
https://people.sap.com/muralidaran.shanmugham2
https://people.sap.com/zhengzhang.lu
https://www.sapsumikko.jp/about
最後に
たくさんのサービスを一同にざっと紹介してきました。
私自身も改めて1つひとつサービスを見つめ直すいいきっかけとなりました。
繰り返しですが、この記事がみなさんの学習のきっかけとなり、SAPコミュニティ、ひいてはBTP普及の一助となれば嬉しいです。
みんなで盛り上げていきましょう!