.net/sap 혼합 시스템이 적합합니까?
https://stackoverflow.com/questions/1471689
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
다소 막연한 질문일 수도 있지만, 실제 생활도 이와 같습니다.
우리 회사는 SAP 시스템을 출시하고 있습니다.이제 그들은 웹 서비스를 수행하므로 C#에서 할 수 있는 모든 작업에 대해 .NET을 동시에 출시할 수 있습니다.
SAP - .NET 통합 과정에서 발생할 수 있는 함정은 무엇입니까?나는 SAP의 논리가 "표준" 프로그래밍과 상당히 다르다는 것을 이해하지만 "비즈니스" 부분과 "프레젠테이션" 부분을 분리하여 ASP.NET으로 작성하고 싶습니다.
해결책
앱이 SAP 포털 통합이 필요하지 않고 고객이 SAP와 같은 모양과 느낌을 요구하지 않으면 원하는 프레젠테이션 계층을 자유롭게 사용할 수 있습니다.
SAP 통합을 선택할 때 SAP 도구를 사용해야한다는 자세에 동의하지 않습니다. NWDI 또는 Old NWD와 같은 제품은 분명한 두통입니다 (여기에 대해 자세히 설명하지 않을 것입니다.
다른 팁
저는 SAP ABAP 및 Microsoft.net 개발자입니다. SAP 및 Microsoft.net, Java 및 ROR과 같은 다른 플랫폼을 사용하여 소프트웨어를 만드는 회사에서 일하고 있습니다.
회사가 SAP를 출시하고 있으므로 RFC 또는 웹 서비스를 사용할 수있는 ECC 6.0 백엔드를 가져와야합니다.
SAP에는 비즈니스 API (일명 BAPI)로 알려진 표준 API가 있습니다. BAPI 거래에서 시도해 볼 수 있습니다.
좋은 예는 이것입니다. BAPI_USER_GET_DETAIL.
이 BAPI는 SAP 사용자에 대한 정보를 반환 할 책임이 있습니다. BAPI에는 사용자 이름이라는 단일 입력 매개 변수 만 필요하며 이메일, 제 1 및 성, 사용자 프로파일 등과 같은 사용자에 대한 정보가있는 다른 데이터 구조를 반환합니다.
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 커넥터 또는 SAP Java 커넥터와 같은 SAP 마법사 커넥터를 사용할 수 있습니다.
최신 버전에서 SAP는 ABAP 용 BSP 및 WebDynPro와 같은 서비스를 실행하기 위해 ABAP 응용 프로그램 서버에 웹 서버를 첨부했습니다. 이 웹 서버를 사용하면 RFC를 웹 서비스로 게시 할 수 있습니다.
그러나 매일의 경험에서 얻은 SAP R/3 성능은 그리 좋지 않습니다. 두 개의 숫자를 합하고 결과를 반환하는 함수에 대한 간단한 RFC 호출은 서버의 avalibility에 따라 1 ~ 5 초에 걸릴 수 있습니다.
이것은 주로 SAP .NET 커넥터 또는 웹 서비스를 사용할 때 발생하는 많은 수준의 추상화로 인해 발생합니다.
따라서 시스템이 매일 거래 할 수있게하려면 (예 : 전자 상거래 애플리케이션에서 매일 5.000 명의 고객을 창출하거나 온라인으로 약 40.000 판매를하는 등의 경우 Java 커넥터를 사용하거나 RFC API를 구현하는 것이 좋습니다. 너 스스로.
그렇지 않으면, 앱이 더 적은 사람들이 내부적으로 사용하는 경우, SAP .NET 커넥터 또는 웹 서비스를 사용하는 것이 좋습니다.
도움이 되었기를 바랍니다!
(링크에 http : // prefix를 추가하십시오. 링크를 게시 할 명성이 충분하지 않기 때문에 :()
RFC API : help.sap.com/printdocu/core/print46c/en/data/pdf/bcfesde4/bcfesde4.pdf
.NET 커넥터 : help.sap.com/saphelp_nw04/helpdata/en/e9/23c80d66d08c4c8c044a3ea11ca90f/content.htm
SAP Java Connector : HELP.SAP.COM/SAPHELP_NW04/HELPDATA/en/6F/1BD5C6A85B11D6B28500508B5D5211/content.htm
ABAP을 사용하여 웹 서비스를 작성합니다 : wiki.sdn.sap.com/wiki/display/stage/service+enabling+in+abap
싸우지 마십시오. SAP를 구현하는 경우 SAP를 구현하십시오. 싸우는 데 어려움을 겪지 않아야합니다.
SAP에는 GUI (BSPS, WDJ, WDA)가 마음에 들지 않으면 프레젠테이션을 처리하는 도구가 있습니다. 나는 당신이 정말로 정말로해야 할 경우 제 3 자 프론트 엔드를 구현하려고하지 않을 것입니다.
몇 가지 일반적인 조언.
- 당신이 "황금 길"이나 그런 것을 찾고있는 것 같습니다. 잊어 버려. Sapland의 어떤 것도 쉽고, 직접적이거나, 잘, 정상적인 것은 없습니다. 모든 방향에는 장애물과 함정이 있습니다. 그러나 절망하지 마십시오. 고통이 정해진 후 SAP는 엔터프라이즈 (무엇이든지)를 놀랍게도 잘 수행합니다.
- 하드 코어 SAP 사용자 (금융, HR, 인벤토리 등을 처리하는 사용자)의 경우 SAP가 제공하는 내용과 함께 가야합니다. GUI는 끔찍할 것이지만 사람들은 놀랍도록 적응할 수 있습니다. 그리고 다른 옵션이 없다면 SAP가 제공하는 것을 좋아하기 위해 성장할 것입니다.
- SAP (Web 또는 Desktop SAPGUI)와 같이 SAP가 제공하는 작업을 수행하는 캐주얼 사용자 (예 : 비용 보고서)의 경우 리소스 낭비입니다. 사용자는 해당 응용 프로그램을 피할 수있는 혁신적인 방법을 찾을 수 있습니다. So.net은 갈 길입니다. 많은 문제가 발생합니다. 그러나 다른 옵션은 더 나쁘다는 것을 기억하십시오.
의견에 대한 응답 :우선 SAP에서 보고서를 수행해서는 안된다고 생각합니다. 보고서는 본질적으로 못 생겼고 SAP는 그들에게 탁월합니다. 나는 사용자의 주요 작업이 아닌 응용 프로그램이 거의 없다고 생각했습니다. 보고 비용보고, 구매 요청 승인 등과 같은 것. 상기로드 블록에서 자료를 어디에서 찾을 수 있는지에 대해. 당신은 할 수 없습니다. 먼저 머리로 그들을 찾아야합니다.
.NET을 사용하는 이유를 잘 생각하십시오.
- .NET 만 사용하지 마십시오 당신이 할 수 있다는 것을 알고 있기 때문에 그것은 좋은 이유는 아니지만 .NET을 사용해야 할 유효한 비즈니스 이유가 있다면 가십시오.
- 일관성을 유지하십시오. 프리젠 테이션 계층이 .NET이어야하는시기와 적절하지 않은시기를 정의하십시오.
- SAP 표준 기능을 "Outwit"하려고 시도하지 마십시오. (저는 사용자 정의하지 말고 말하지 않습니다. 저는 SAP Prefered 옵션을 사용하여 향상, 사용자 출구 등을 사용하고 더 나은 제품과 더 나은 SAP 지원을 얻을 수 있습니다. 오퍼링을 이해하려고 시도하면 SAP를 구현할 수 없습니다. 충분히)
- "단지 하나의 규칙"은 없으며 사용자/고객의 요구를 이해해야하며 고객이 직면 한 웹 사이트에 .NET을 사용한다고해서 관리보고 또는 간단한 ALV에 비즈니스 객체를 사용할 수 없다는 의미는 아닙니다. 대부분의보고를위한 그리드
- Web Dynpro는 ABAP 개발자를 위해 배우기가 어렵지 않으며 SAP Space Web Dynpro 외부에서 개발자를 훈련시켜야한다면 학습 곡선 중 가장 적습니다. SAP Business Logic은 훨씬 어렵고 Core를 깨지 않고 SAP 표준을 지원하는 방법으로 SAP 표준을 재사용하는 방법은 ABAP 도구 세트를 배우는 것보다 더 어려운 일입니다.
저는 다양한 .NET/SAP 구현에 참여해 왔습니다.한편으로는 ABAP에서 원하는 것을 작성하는 대신 .NET을 사용하지 않는 것이 좋지만 다른 한편으로는 합리적으로 잘 작동하도록 만들 수 있습니다.위에서 누군가가 언급했듯이 소규모 트랜잭션의 경우 웹 서비스에 대한 오버헤드가 높을 수 있으므로 상당한 양의 데이터가 한 번에 전달되도록 설정하십시오(예:전체 화면이 가득 찼습니다).이는 또한 SAP가 한 번에 소량의 항목을 전달하고 상태를 처리하는 대신 전체 트랜잭션을 처리하거나 내부적으로 더 많이 처리할 수 있음을 의미합니다.비즈니스 로직은 SAP 내부에서 구현되어야 하며 .NET 부분은 데이터 표시/교환만 처리합니다.
두 번째로는 Expenses 인터페이스에 대해 말한 내용을 설명하겠습니다.대부분의 사람들은 다른 공급업체의 소프트웨어를 사용하여 외부에서 이 작업을 수행하지만 비용 데이터를 가져오기 위해 멋진 실시간 .NET을 사용할 필요는 없으며 하루에 한 번 가져오는 간단한 배치 작업만 있으면 됩니다.때로는 가장 간단한 방법이 가장 좋습니다.
우리 회사에서 우리는 같은 상황에 처해 있습니다. .NET을 사용하여 SAP와 통합 프로젝트를 수행하고 있습니다.
.NET에서 직접 BAPI 기능을 실행하여 웹 서비스를 피할 수 있습니다. 오늘 저는 표준 RFC 기능이 BAPI 기능으로도 노출 될 수 있다는 것을 알게되었습니다.
우리는 사용 중입니다 ERP 연결 Theobald 소프트웨어에서 BAPI/RFC 기능을 직접 실행 하고이 토론에서 언급되지 않았기 때문에 아는 데 도움이 될 것이라고 생각했습니다.
무료는 아니지만 개발자의 삶이 훨씬 쉬워 질 것이라고 생각합니다.
Theobald Software와 어떤 식 으로든 제휴하지 않습니다.
