More than 5 years have passed since last update.

(翻訳)SAP Cloud Platform ABAP Environment

Posted at 2019-10-09

訳者コメント

SAP Cloud PlatformでABAPがいじれるようになったみたいです。

一介のABAPerとしての勉強、兼英語力のリハビリのため、ブログを翻訳してみました。

かかった工数は、トータル2人日くらいです。
想像していたより、大変でした。
ちょいちょいウィットに富んだ比喩が使われているため、結構苦労しました。

ここから

それでは、解説します！
SAP Cloud Platform ABAP環境をいますぐ使ってみましょう！

このブログでは、ABAPプラットフォームをクラウドサービスとして使えるという意味で、SAP Cloud Platform ABAP環境の事をABAP PaaSと呼びます。SAPの歴史上初めて、世界中の開発者がクラウドでABAPコードを構築して実行できるようになりました。SAP Cloud Platformでは、ABAPはJavaやNode.jsと同じくらい誰にでも使える言語となりました。

去年耳目を集めた我々が、それ以降まったく鳴りを潜めていた思いますか？(そう思っていない場合、この段は飛ばして読んでください。) これだから、気の早い噂話は気に入らないのです。LinuxにR / 3を実装した1998年の古き良き時代を思い出します。Linuxへの移植が完全に完了するまで、我々はその事をSAPの内外の誰にも話しませんでした。
Hasso(訳注：SAP SEソフトウェア会社の共同設立者) がオープンソースとLinuxがどれほどクールかを確信するに至って初めて、CeBIT 1999でメッセージを広めることになったのです。それは私の今までの人生で最高の時間でした。

今では事情は少し異なっています。さらに、OSの移植と比較して、クラウドが普及していなかった時代にルーツを持つコードからABAP PaaSを派生されることは、かなり面倒な作業です。事実、作業完了には程遠い状況です。我々はまだ実行可能なプログラムのうちの最低限の部分を移植し始めたにすぎません（最低限などとは言いたくないところですが）。さっさと、そして何度もリリースし、顧客の声に耳を傾けることは、LinuxでR / 3を実装したオープンソースのスローガンの1つです。そして、我々は現在、ABAP PaaSでも同じことをしています（そうそう、"耳を傾ける"事も忘れちゃいません）。

クラウドの救いな点は、オンプレミスようにABAPコミュニティによって別バージョンのリリースがそれぞれ独自に作られたりしない事です。読者の中には、まだABAP 4.6C(その中核の開発メンバーとして貢献できたのは私にとって幸せな時間でした。)を使用している人もいれば、最新のS / 4HANAに取り掛かっている人もいるでしょう。ABAP PaaSは、常に最新かつ唯一のリリースしか存在しません。私たちは全員で、同時にそれを共有でするのです。これにより、利用者のフィードバックを収集し要望を反映しやすくなります。あなたやあなたの会社が数年後にインストールしようとしているリリースではなく、あなたが今使っているABAP PaaSにです。

私にとって、ABAP PaaSに携われた事はSAPでの30年近くのキャリアの中で非常に特別な瞬間です。私たちは現在、今後10年以上の礎を築いているのです。この作業を担う素晴らしいチームの一員である事を本当に誇りに思います。そして、ボリス・ゲブハルト（ABAPプラットフォームのチームプロダクトオーナー）、フランクジェンシュ（ABAP PaaSのプロジェクトリーダー）、カールケスラー（製品管理者）のような友人に囲まれて非常にうれしく思います。皆さん、どうもありがとうございました。皆さんがいなければ、私は途方に暮れていたし、ABAP PaaSがリリースされる事も無かったでしょう。

ハラルド
2018年9月4日

よくある質問

全般

このFAQの主たる目標は、期待に誠実に答える事です。このセクションでは、ABAP PaaSの事ならどんな事にでも興味があるあなたの、基本的な質問に答えます。既存のABAPとABAP PaaSの違いの詳細については、開発セクションまでスクロールしてください。

[Q1]要するに、ABAP PaaSでは何がどうなったのですか？

あなたはABAP開発者ですか？
要するにクラウドでコードを作成できるようになったという事です。そして、そう、あなたのオンプレミスのABAP体験と比べると少し違和感を持つかもしれません。これからは、常に最新かつ最高のABAPおよびSAP HANA機能や、SAP Cloud Platformが提供するマイクロサービスを利用できます。また、SAPはABAPプラットフォームとHANAレイヤー全体を運用しているため、フォローアップが必要なく、アップグレード後の面倒なタスクに悩まされることもなくなります。

あるいはあなたは、既存のビジネスソリューションを使用してSAP S/4HANA Cloudを導入しようとしているユーザー様ですか？
それなら、ABAP PaaSは、オンプレミスのABAP拡張機能をクラウドに変換し、カスタムコードを最新化して安定稼働させ、ABAPチームのスキルを向上させる絶好の機会です。
ABAP PaaSを使わないのなら、今後数年間SAP ERPまたはSAP S / 4HANAシステムをオンプレミスのままにするつもりですか？

今のところ、従来のABAPカスタム開発を続けることに問題はありません。しかしあなたにとって、ABAP PaaSは革新的で独立したアドオン機能を作成するためのベストな選択肢です。実装言語に関係なく、SAP HANAやその他のSAP Cloud Platformサービスをクラウドで実行できるというシナリオについて考えてみてください。しかもそうしたシナリオはすべて、安定したデジタルコアであるオンプレミスERPシステムを阻害せず負担をかける事もないのです。独立したAPIを使って隔離された手法により、次回のアップグレードを複雑にする拡張やモディフィケーションをERPに施す時代は終わりました。この発表を聞いたことがないので、少し困惑しているって？

ここに、簡単にまとめられています。
主な構成がわかるような、シンプルな図が欲しいって？どうぞ:

Cloud Cockpitを使ってABAP環境を作成して保守し、ABAP Development Tools for Eclipse(ADT)を使ってABAPコードを作成し、Gitを使ってコード交換とバージョン管理を行います。ABAP PaaS自体は,HANAなどのサービスを利用可能なSAP Cloud Platformに統合された一部分です。ABAPプログラミング環境の詳細については、後述の開発者向けセクションを参照してください。
ABAP PaaSに関するご意見、ご感想は、

の早期導入ケアプログラムを通じてお寄せください。

[Q2] SAP Cloud PlatformでJavaやNodeが書けるのに、なぜABAPを検討する必要があるのでしょうか。

そうですね。クラウドについて語るとき、ABAPは最初に思い浮かぶものではないでしょう。まず第一に、これは自由な選択の問題で誰も無理強いはしません。

SAPデジタルコア(訳注：S/4 HANAの事)の大部分はABAPをベースにしています。つまり、ABAPで記述された山のようなアドオン機能と同じくらい、世界中に多くのABAPのソースが存在することを意味します。そのようなABAPソースは、まさにABAP PaaSにとって独壇場です。ABAP PaaSの非機能的特性が十分に適合するシナリオでは、既存のABAPスキルやあるいはコードの一部さえも、をクラウドで再利用できることは大きなメリットになります。(下記の開発者向けセクションを参照)

それとは別に技術的な観点からすると、データ型と構造が近接しているため、ABAP拡張機能を使ってABAPアプリケーションの領域をカスタマイズすることは、おそらく最悪の選択とは言えないと思われます。

私たちは、ユーザーの現状からスタートして、そしてクラウドへの移行を支援する事がベストだと信じています。その目的のためには、ABAP PaaSが本当に役に立ちます。

[Q3] ABAPコミュニティには長い要望リストがあります。バージョン管理について考えてみてください。一体なぜABAP PaaSで時間を無駄にしているのですか？

前述したように、ABAP PaaSを動機づける2つの主なユースケースは以下の通りです。
1:分離されたABAPコードでS/4HANA Cloudを拡張する
2:分離されたABAPコードを使用して、オンプレミスABAP拡張機能をクラウドに変換する

次の3つ目は特筆すべき点です。

3:ABAP環境を最新化する

これは、ABAP PaaSをイノベーションのフロントランナーとして利用できるようになったことを意味しており(Q12を参照)、前述の通り、あなたにもABAP PaaSの将来のために力を貸して欲しいし、フィードバックをして欲しいのです。

潜在的な無駄について：クラウドでは、ABAPプラットフォームは2つの特色を備えています。言い換えると2つの異なる役割を果たしています。一つめは、S / 4HANA CloudのようなSAP社のより大きなSaaSソリューションの内部基盤としてです。この意味では、ABAPプラットフォームは、SaaSソリューションの潜在的な成功要因となっております。もう1つの役割はABAP PaaSであり、ABAPの上にSaaSソリューションを構築して実行したければ世界中の誰であっても使える、というものです。

どちらの特色も、ABAPカーネルとABAPレイヤーの共通コードラインに基づいています。また、ABAPとクラウド（およびオンプレミスのS / 4HANA）に関連するSAP投資のほとんどは、この共通のコードラインに対するものであるため、無駄はありません。

バージョン管理については、ご心配なく、はっきりとお答えします。(下記のGitの質問を見てください。)

[Q4] 最初のバージョンでは具体的に何ができますか? 適当にいじってみたり、実際に使ってみろと?

ABAPは当初からビジネスアプリケーションを効率的に記述および実行することを目的としていましたが、これはABAP PaaSでも変わりません。スタンドアロンのビジネスアプリケーションや、クラウドやオンプレ、S/4HANA、従来のERPなどのデジタルコアの拡張機能を開発できます。
ABAP PaaSの最初のバージョンの焦点は、S / 4HANA Cloudの拡張機能です。心配しなくても、2018年には、オンプレミスのシステム(外部へのリモート・ファンクション・コール(RFC))への接続が計画されています。また、ABAPでサービスを開発し、HTTP (S) またはODataを介して公開することもできます。
ABAP PaaSで今日構築できるものの例として、内部デモで使用している次のシナリオやユーザストーリーを考えてみてください。営業担当者がOpenStreetMapを使用して、近隣の潜在的な新規顧客を見つけたいとします。いくつかの顧客候補を集めた後、顧客データを作成して編集し、最終的にS/4HANA Cloudアカウントに同期させたいと考えています。
ABAP PaaSの最初のバージョンでは、使える範囲は制限されています。時間の経過とともに成長しますし、（できればその過程であなたのフィードバックや貢献を頂きたいのですが）、今からでも実際のアプリケーションやサービスを書くことができます。

[Q5] ロードマップとビジョンは?

ABAP PaaSの最初のバージョンが焦点を当てているのは、S/4HANA Cloudを拡張するためにゼロから書かれたコードです。次にやるべき作業には、カスタムコードの移行のサポートと、オンプレミスのソリューションの拡張が含まれます。

2019年には、ABAP PaaS上で顧客向けにアプリを開発および実行するパートナーに対して、より良いサポートを提供する予定です（SAP App Centerとの統合、またはマルチテナンシーによる限界費用の最適化を想像して下さい）

開発者目線でのQA

このセクションでは、経験豊富なABAP開発者が聞いてくる可能性の高い質問に回答します。ABAP PaaSとオンプレミスABAPの違いは何か、機能Xはサポートされているか、既存のコードを再利用できるか、などについてです。

[Q6] SAP GUIやWeb Dynproはなく、ABAP言語の機能とAPIが限られていると聞きました。なぜそんなに制限されるのですか？オンプレミスシステムで行うように開発できないのはなぜですか？

クラウドには新たな責任分担が必要です。この場合、ABAPプラットフォームとSAP HANAレイヤーを管理し、ランドスケープ全体を操作して、新しい機能と修正を継続的に提供するのが供給者（SAP）の役割です。層の一番上のコードはすべて、持ち主であるあなた(訳注：開発者)が管理する事になります。これは各レイヤーの所有者と供給者が、あるいは所有者同士が明確に分かたれているからこそできることです。我々は供給者として、所有者のコードに影響を与えることなくプラットフォームを交換できるようにしておく必要があります。

まさにこのために、我々供給者とあなた方所有者との間の領域を明確に区別するインターフェース、つまりABAP言語からCDSビューまでのサポートされているABAP成果物のホワイトリストが必要なのです。
このホワイトリストは、時間の経過とともに拡張していきます。あなたにもホワイトリストの作成にご協力いただければ幸いです。ただし、ホワイトリストでサポートできるのは、上記の分離タイプのいずれかに該当する成果物のみであり、互換性のない変更を導入してはなりません。最後になりますが、ホワイトリストが提供できるのは、セキュリティやパフォーマンスなど、製品標準に関して妥当な努力で適合できる成果物だけです。

これが、私たちがABAP PaaSを少しずつ拡大する理由であり、SAP Guiをサポートする代わりにRESTfulサービスのみを公開する理由であり、ファイルシステムへ直接アクセスできないようにしている理由です。

(訳者注：RESTfulサービスとはRESTful APIの事かと思われる。詳細は下記のリンクを参照
https://qiita.com/NagaokaKenichi/items/0647c30ef596cedf4bf2
)

[Q7] わかりました。では、ABAP PaaSにとって前述の点は何を意味するのですか？

ABAP PaaSの性質と範囲に関する基本原則は次の通りです。

あくまでもABAPのサブセットである事。新しい言語を作ったのではなく、適切なサブセットを作成したのです。
クラウドである事。クラウドの運用を中断したり危険にさらしたりはできません。
統一性：シンプルさを維持し、運用リスクを軽減します。UIや出力管理のようなコンポーネントでについては、従来のものすべてが使えるわけではなく、ひとつの戦略的なCloudバリアントのみをサポートします。
小規模から始める事–ホワイトリストを安定させておく必要があるため、小規模なホワイトリストからサービスを開始して段階的に拡張します。
お客様の声に耳を傾ける事–私たちは早期導入者やABAPコミュニティと協力して,バックログのランク付けを行っています。
実用本位なアプローチ-我々はモダンで美しいABAPプラットフォームと再利用されている既存のABAPコードのバランスを見つけられるよう試行錯誤しています。そして、あなたにはウィッシュリストをオープンにして頂きますが、私たちはあなたがソースからPERCENTAGE percをデスティネーションとしてMOVEしたいなどと主張しないことを切に願っています。

これらの原則を実施するために、ABAP PaaSは設計時にアプリケーションコードをチェックします。これらの規則に違反する開発オブジェクトは、構文エラーにつながります。静的にチェックできないコードはサポートされていません。現在、動的ABAPプログラミング機能をサポートするため、追加のランタイム・チェックを評価しています。

[Q8] 上記原則はUI、言語、SAP HANAアクセスに対してどう影響しますか？

UI
ABAP PaaSは、ODataまたはプレーンHTTPのみを介して利用できます。 SAP GUI、Web GUI、Web Dynpro、BSPなどの従来のABAP UIテクノロジーは利用できません。ABAP PaaSのサービスは、Fiori UIまたはその他のWebベースのUIフレームワークで使用できます。

SAP HANA
ABAP操作をよりセキュアにするために、HANAオブジェクトへのアクセスはABAP管理でのみサポートされています。これには、ABAP SQL、コアデータサービス（CDS）、およびABAP管理データベースプロシージャ（AMDP）が含まれます。ネイティブHANAアーティファクトまたはネイティブHANAアクセスはサポートできません。

ABAP言語
ABAP PaaSは、ABAP言語の特別なクラウドバージョンを使用します。クラウド操作に害を及ぼす可能性がある、または制御できないステートメント（ローカルファイルアクセス、カーネル呼び出し、EXEC SQL、GENERATE REPORTなど）は使用できません。また、dynproテクノロジーはABAP PaaS製品の一部ではなくなったため、廃止されたステートメントは削除され、CALL SCREENなどのステートメントはサポートされません。

ABAP再利用サービスと再利用要素
ABAP PaaSは、再利用レイヤーのBASISおよびABAの既知のオブジェクトのホワイトリストに登録されたサブセットを提供します（CDSビューまたはABAPクラスなど）。

さらに、ABAP PaaSは、宛先、UIリポジトリ、印刷またはID管理に関するいくつかの技術的なABAPサービスを置き換えるか、または適応させます。 ABAP PaaSでは、これらのサービスはSAP Cloud Platformサービスを呼び出すことで実装されます。

ABAPプログラミングモデル
FioriおよびODataサービスの場合、新しいRESTful ABAPプログラミングモデル（RAP）が実施されます。ゲートウェイサービス（SAPゲートウェイサービスビルダーSEGW）またはBOPFを使用する古いバージョンのFioriプログラミングモデルはサポートされていません。

標準のREST / HTTPサービスを構築するために、ABAP PaaSは新しいホワイトリストに登録されたABAPインターフェイスを提供します。

[Q9]初版のバージョンのホワイトリストに含まれるABAPオブジェクトとAPIはどれですか？

最初のABAP PaaSバージョンのホワイトリストには、400以上のABAP開発オブジェクト（クラス、インターフェース、CDSビュー、データ要素など）が含まれ、日付と時刻の変換、XML処理、アプリケーションログなどのコアABAPサービスに焦点を当てています。ホワイトリストが次のバージョンで大幅に増加することは間違いありません。
より多くの技術サービスの後、番号範囲、工場カレンダー、変更文書などのビジネス再利用サービスをホワイトリストに登録する予定です。

[Q10] ABAPのノウハウを本当に再利用できますか？

SAP HANAのABAPコード、Fioriアプリ、EclipseのABAP、あるいは単体テストに既に慣れていますか？

もしそうなら、ABAP PaaSで最初のアプリやサービスを開発して実行するのはほんのわずかのステップです。必要なのは、RESTful ABAPプログラミングモデル（RAP）の学習を少し始めるだけです。

なぜSE80とSAP GUIでは対応できないのかですって？

もしかすると、ここ数年の間にABAPコミュニティのために開発された新しい機能すべてにチャンスを与えるべきなのかもしれません。（慣れてないからといって）パニックにならないでください。トレーニング・コースとチュートリアルが豊富に用意されています。これまでABAPを気に入っていたなら、がっかりすることはまずないでしょう。

[Q11] z-Code(注：開発者が登録するERPのアドオン)をABAP PaaSにコピペすることはできますか？

まず、良いニュースです。コピー＆ペーストがサポートされています。

次に悪いニュースです。オンプレミスコードをABAP PaaSにコピーするだけでは、多くの構文エラーが表示されます。さらに深刻なのは、既存のオンプレミスABAPコードのうちABAP PaaSで実際に再利用できるものがどれだけあるかということです。コード次第となるため予測はしづらいですが、見通しを立ててみます。

既存のオンプレミスABAPコードの再利用が利用しづらいのは、下記のABAP PaaSの部分です。再利用への影響によってランク付けしています。

1:コアビジネスシステムとサイドバイサイド(訳注：side-by-side 実行のこと。複数バージョンのアセンブリを分離して、同時にインストールおよび使用するための機能。）で実行されるABAP PaaS
2:ホワイトリストに登録されたテクノロジー（SAP GUIは以外）
3:ホワイトリストに登録されたSAPオブジェクト（SAPテーブルへの直接アクセス以外）
4:ホワイトリストに登録されたABAPステートメント（OPEN DATASET以外）

既存のカスタムコードをPaaSに再利用するのが最も難しいのは、サイドバイサイドアプローチと、GUI / dynproテクノロジーがサポートされていない部分です。１つ１つ見ていきましょう。

オンプレミスのNetWeaverですでに、多くのハブシナリオや個々に共存している拡張機能を見てきました。これらのシナリオと同様に、ABAP PaaSアプリはリモートAPIを介してコアビジネスシステム(注:Sｐ/4Hの事)と通信します。したがって、コアビジネスシステムのビジネスロジックに疎結合されているカスタムコードは、ABAP PaaSへの移行対象として良い候補となります。

一方、ビジネスプロセスと深く統合されたオンプレミスのカスタムコードの方はというと、コアシステムにとどまる必要があります。そのようなコードは、S/4HANA Cloudのいわゆるアプリ内拡張機能に相当します。こうした密結合シナリオにおいて、これは使用するのに適切なメカニズムです。疎結合シナリオでも、アプリ内拡張機能/カスタムコードとABAP PaaSアプリケーションの組み合わせが最適な場合がよくあります。

要約すると、すでにFiori UIを使用しているカスタムNetWeaverアドオンまたは疎結合カスタム拡張機能がある場合、ABAP PaaSで再利用できるコードは非常に多くなります。他のすべてのシナリオでは、再利用は主にビジネスロジックに限定されます。 ABAP PaaSで再利用できるビジネスロジックの量は、カスタムコードのアーキテクチャによって異なります。コードを再利用するにあたって最もメリットが大きいのは、UIコード、カスタムビジネスコード、SAPコードを明確に分離することです。

[Q12]イノベーションの最前線としてのABAP PaaS？どういう意味ですか？

ABAP PaaSは、四半期ごとに定められた日にSAPによって自動的に更新されます。イノベーションは最初にABAP PaaSにもたらされ、その後可能性次第で他のABAPベースのソリューションに展開されます。

ここで、ABAP開発プロセス全体のリノベーションが始まります（以下を参照）。あなたは、RAPに基づくFioriプログラミングモデルが最新かつ非常に効果的であるという印象を持つでしょう。 ABAPで直接グラフ、階層、地理空間などのSAP HANA機能が使えるのを目にできるのですから。また、ID認証、ポータル、モバイル、IoT、機械学習などのSAP Cloud PlatformサービスでABAP PaaSアプリを拡張させる事もできます。

[Q13] Gitはどうですか？

私たちは最後までベストを尽くしました。 ABAP PaaSはコード交換とコード展開にGitを使用します。

コード交換のユースケースでは、コミュニティプロジェクトでABAPコードまたは他のABAP成果物を共有したり、Gitを介してABAPシステム間でABAPコードを交換したりできます（たとえば、オンプレミスシステムからABAP PaaSにカスタムコードを転送する）。コード交換のために、ABAP PaaSは有名なオープンソースソリューションabapGit（ http://docs.abapgit.org ）を使用します。

コード展開のユースケースは、ABAPコードと他のABAPアーティファクトをABAP PaaSシステム間で転送することです（たとえば、開発システムからテストシステムに）。 ABAP PaaSの最初のバージョンでは、標準のABAPトランスポート管理システムの内部でコードをデプロイするためにGitを使用しています。

これまで、ABAPのバージョン管理はかなり制限されており、分岐、マージ、またはCI / CD（継続的統合/配信）ツールチェーンのサポートはほとんどありませんでした。我々の目標は、ABAPの変更とトランスポートシステムの利点を犠牲にすることなく、Gitなどのバージョン管理システムを使用して、ABAPを段階的に革新することです。