5

これは少し漠然とした質問かもしれませんが、実際の生活はこのようなものです。

当社はSAPシステムを展開しています。彼らが現在Webサービスを実行していることを知っているので、C＃で実行できることがわかっているすべてのことに対して.NETを同時に展開できます。

SAP-.NET統合の過程での落とし穴は何ですか？SAPのロジックは「標準」プログラミングとはかなり異なることを理解していますが、ASP.NETで記述されるように、「ビジネス」部分と「プレゼンテーション」部分を分離したいと考えています。

4

7 に答える 7

13

私はSAPABAPおよびMicrosoft.NETの開発者です。私は、SAPと、Microsoft.NET、Java、RoRなどの他のプラットフォームを使用してソフトウェアを作成する会社で働いています。

あなたの会社はSAPを展開しているので、RFCまたはWebサービスを使用できるECC6.0バックエンドを入手する必要があります。

SAPには、Business API（別名BAPI）と呼ばれる標準APIがあります。BAPIトランザクションで試すことができます。

1つの良い例はこれです：BAPI_USER_GET_DETAIL。

このBAPIは、SAPユーザーに関する情報を返す責任があります。BAPIは、USERNAMEと呼ばれる単一の入力パラメーターのみを必要とし、電子メール、姓名、ユーザープロファイルなど、ユーザーに関する情報を含むさまざまなデータ構造を返します。

ABAP内では、このBAPIを呼び出すためのテンプレートは次のようになります。

CALL FUNCTION 'BAPI_USER_GET_DETAIL'
EXPORTING
USERNAME = sy-UNAME
* IMPORTING
* LOGONDATA =
* DEFAULTS =
ADDRESS = L_IT_RETURN1
* COMPANY =
* SNC =
* REF_USER =
* ALIAS =
* UCLASS =
* LASTMODIFIED =
* ISLOCKED =
TABLES
* PARAMETER =
* PROFILES =
* ACTIVITYGROUPS =
RETURN = L_IT_RETURN
ADDTEL = i_Tel
* ADDFAX =
* ADDTTX =
* ADDTLX =
* ADDSMTP =
* ADDRML =
* ADDX400 =
* ADDRFC =
* ADDPRT =
* ADDSSF =
* ADDURI =
* ADDPAG =
* ADDCOMREM =
* PARAMETER1 =
* GROUPS =
* UCLASSSYS =
* EXTIDHEAD =
* EXTIDPART =
* SYSTEMS =.

現在、すべてのBAPIでRFC（リモート関数呼び出し）も有効になっています。つまり、アプリケーション内にSAP RFC APIを実装する場合、RFCが有効に設定されているSAP内の任意のBAPIまたはその他の関数を呼び出すことができます。

古いバージョンでは、標準のSAP RFC APIを使用するか、SAP.NETコネクタやSAPJavaコネクタなどのSAPウィザードコネクタを使用できました。

新しいバージョンでは、SAPは、ABAP用のITS、BSP、WebDynproなどのサービスを実行するために、そのABAPアプリケーションサーバーにWebサーバーを接続しています。このWebサーバーを使用すると、RFCをWebサービスとして公開できます。

しかし、私の日常の経験からすると、SAP R/3のパフォーマンスはそれほど良くありません。2つの数値を合計して結果を返す関数への単純なRFC呼び出しは、サーバーの可用性に応じて1〜5秒かかる場合があります。

これは主に、SAP.NETコネクタまたはWebサービスを使用しているときに発生する多くのレベルの抽象化が原因で発生します。

したがって、システムを毎日のトランザクション（eコマースアプリケーションから毎日5.000の顧客を作成する、オンラインで約40.000の販売を行うなど）で利用できるようにする場合は、Javaコネクタを使用するか、RFCAPIを実装することを強くお勧めします。あなた自身の。

それ以外の場合、アプリが内部で使用される人が少ない場合は、完全にGTD指向であるという理由だけで、SAP.NETConnectorまたはWebServicesを使用することをお勧めします。

お役に立てれば！

（以下のリンクにhttp：//プレフィックスを追加してください。リンクを投稿するのに十分な評判がないためです:(）

RFC API：help.sap.com/printdocu/core/Print46c/EN/data/pdf/BCFESDE4/BCFESDE4.pdf

SAP .NETコネクタ：help.sap.com/saphelp_nw04/Helpdata/EN/e9/23c80d66d08c4c8c044a3ea11ca90f/content.htm

SAP Javaコネクタ：help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5c6a85b11d6b28500508b5d5211/content.htm

ABAPを使用したWebサービスの作成：wiki.sdn.sap.com/wiki/display/stage/Service+Enabling+in+ABAP

于 2009-12-08T03:34:44.610 に答える
7

アプリが SAP ポータルの統合を必要とせず、クライアントが SAP のようなルック アンド フィールを要求しない場合は、好きなプレゼンテーション レイヤーを自由に使用できます。

SAP 統合を行うことを選択した場合、SAP ツールを使用する必要があるというスタンスには同意しません。NWDI や古い NWDS のような製品は明らかな頭痛の種です (ここでは詳しく説明しません。長い話です)。100% 専任の SAP インテグレーターでない場合、Webdynpro を学ぶように人々をトレーニングすることは、私の意見ではお金の価値がありません。

于 2009-09-24T14:02:08.253 に答える
4

一般的なアドバイスはほとんどありません。

  • 「ゴールデンパス」などを探しているようです。忘れてください。サプランドでは、簡単なこと、率直なこと、または普通のことは何もありません。あらゆる方向に障害物と落とし穴があります。しかし、絶望しないでください。痛みが落ち着いた後、樹液はそのエンタープライズ（それが何であれ）のことを驚くほどうまく行います.
  • 筋金入りの sap ユーザー (財務、人事、在庫などを処理するユーザー) の場合は、sap が提供するものを使用する必要があります。GUI はひどいものですが、人々は驚くほど順応性があります。そして、他の選択肢がなければ、樹液が提供するものを愛するようになります.
  • カジュアルなユーザー (経費報告書など) にとって、sap が GUI として提供するもの (Web またはデスクトップ sapgui) でそれを行うことは、リソースの無駄遣いです。ユーザーは、これらのアプリケーションを回避するための革新的な方法を見つけるでしょう。So.net が最適です。多くの問題に遭遇します。ただし、もう一方のオプションの方が悪いことに注意してください。

コメントへ の返信: まず第一に、レポートは SAP で行うべきではないと思います。レポートは本質的に醜いものであり、樹液はそれらに優れています。ユーザーの主な作業ではない小さなアプリケーションを考えていました。経費の報告、管理者による購入依頼の承認など。上記のロードブロッキングのどこで資料を見つけることができますか。できません。最初に頭でそれらを見つける必要があります。

于 2009-09-24T21:49:57.987 に答える
3

それと戦わないでください。SAPを実装している場合は、SAPを実装するだけです。それと戦うのに苦労する価値がないことはほぼ保証されています。

SAPには、GUI（BSP、WDJ、WDA）が気に入らない場合にプレゼンテーションを処理するためのツールがあります。あなたが本当に本当にそうしなければならないのでない限り、私はサードパーティのフロントエンドを実装しようとはしません。

于 2009-09-24T13:56:43.730 に答える
2

.NET を使用する理由をよく考えてください。

  • .NET を使用できることがわかっているからといって.NET を使用するのは適切な理由ではありませんが、.NET を使用する正当なビジネス上の理由がある場合は使用してください。
  • 一貫性を保ちます。プレゼンテーション レイヤーを .NET にする必要がある場合と、適切でない場合を定義します。
  • 本来の意図とは異なる動作を強制することで、SAP 標準機能の「裏をかく」ことを試みないでください。(カスタマイズするなと言っているのではありません。拡張機能やユーザー エグジットなどの SAP 推奨オプションを使用すると、より優れた製品とより優れた SAP サポートが得られると言っているのです。提供内容を理解しようとせずに SAP を実装することはできません。完全に）
  • ユーザー/顧客のニーズを理解するために必要な「ルールは 1 つだけ」というわけではありません。顧客向けの Web サイトに .NET を使用しているからといって、管理レポートや単純な ALV にビジネス オブジェクトを使用できないわけではありません。レポートの大部分のグリッド
  • WEB Dynpro は、ABAP 開発者が習得するのはそれほど難しくありません。SAP スペースの外から開発者をトレーニングする必要がある場合、WEB Dynpro は学習曲線の中で最も簡単です。SAP ビジネス ロジックははるかに難しく、コアを壊さずにサポートされている方法で SAP 標準を再利用する方法は、ABAP ツールセットを学習することよりも大きな課題です。
于 2009-09-29T06:24:53.677 に答える
1

私は数多くの .NET / SAP の実装に携わってきました。必要なものを ABAP で記述するだけではなく、.NET を使用することはお勧めしませんが、一方では、かなりうまく機能させることができます。上で述べたように、小さなトランザクションでは Web サービスのオーバーヘッドが高くなる可能性があるため、かなりの量のデータが一度に渡される (つまり、画面全体がいっぱいになる) ように設定してみてください。これは、一度に少量のものを渡して状態を処理する代わりに、SAP がトランザクション全体またはそれ以上を内部的に処理できることも意味します。ビジネス ロジックは SAP 内に実装する必要があり、.NET 部分はデータの表示/交換のみを処理します。

Expenses インターフェースについて述べたことを 2 番目に取り上げます。ほとんどの人は、別のベンダーのソフトウェアを使用して外部でこれを行っていますが、費用データをインポートするために高度なリアルタイム .NET を使用する必要はありません。1 日に 1 回インポートする単純なバッチ ジョブを使用するだけです。最も単純な方法が最善の場合もあります。

于 2010-02-08T13:32:54.553 に答える
1

私の会社も同じ状況です。.NETを利用したSAPとの統合プロジェクトを実施中

.NET から直接 BAPI 関数を実行することで、Web サービスを回避できます。今日、標準の RFC 関数を BAPI 関数としても公開できることを知りました。

私たちはtheobald ソフトウェアのERP Connectを使用して bapi/RFC 機能を直接実行しています。

これは無料ではありませんが、開発者の生活をずっと楽にしてくれると思います。

私は theobald ソフトウェアとは一切関係がないことに注意してください。

于 2012-10-05T14:06:56.403 に答える