iamyhs

주의사항)
SAP 용어를 그대로 쓴다, 이런 용어마저 익숙하지 않다면 SAP 에대한 기본서를 먼저 본다.
더불어 FM(Function Module)을 디버깅할때쓰이는 SAPGui 에 관련된 내용도 SAP 용어를 그대로 쓴다.

1)JCO vs JCA
현재 참여하고 잇는 프로젝트는 위 두 환경이 공존하고 있다.
    
    1-1)로컬 테스트는 JCO
    1-2)실제 Deploy는 JCA 환경

    이유 : JCO 로 했을때, SSO(Single Sign On) 정보를 SAP의 ECC 정보가져올때(Landscape) 유지할수가 없었다.(정말 안되는지는 미 검증)
        JCA로 했을때는 SSO 문제가 해결되어있고, JCA 자체가 표준 아키텍처 이므로 이 방식으로 개발하고 있다.



2)WebService vs FDS
    SAP 쪽 데이타를 WebService 이용해서 가져오는 방식, SAP<->Flex
    SAP 쪽 데이타를 Remote Object를 이용해서 가져오는 방식, SAP<->JAVA<->Flex


3)XML용 파서, FDS용 파서

    3-1)WebService를 이용할때 : XML(텍스트) 대량의 데이타를 주고 받는 환경에서는 부적합(속도,용량)

    3-2)FDS를 이용할때 : AMF(Binary)    대량의 데이타를 주고 받을때 적합

    3-3)XML
        DataType : XML

    3-4)FDS
        DataType : AMF(Binary)
        SAP FM(RRW3_GET_QUERY_VIEW_DATA)을 이용

4)SAP GUI 디버깅
    이 게시물을 참고


5)SAP 데이타구조에 대한 Online Help
Default Variables for Web Applications
                
Datasets


6)SAPGui 사용법을 알아야 한다, 가장 기본적인 서버세팅부터, TCode 같은것들 등등

7)기본적인 Bex Query Designer 사용법을 익혀야 한다.

8)파서를 직접 제작 혹은, 업그레이드 하고 싶다면 FM 자체를 디버깅하는 방법과, SAP 데이타의 구조를 파악해야한다

9)위험요소
현재 쓰이고 있는 RRW3_GET_QUERY_VIEW_DATA이 표준 FM이 아니다.SAP 쪽에서 Max Attention 방식의 별도 관리가 필요한 부분이기도 하다.

현재 SAP 프로젝트에 쓰고 있는 RRW3_GET_QUERY_VIEW_DATA FM이(Function Module) 스탠다드가 아니란다.

SAP 쪽 전문가가 아니어서 뭐라고 말할수가 없지만, 왜 이걸 이제 알았을까.

그 적지않은 관계자들은 무슨 생각을 한걸까.

이 참에 동료 개발자들과 "초난감 프로젝트의 조건"을 집필할까 한다.

여러가지 면에서볼때 책나오면, 벌써 대박 예감이다.

규모가 큰 프로젝트의 전형적인 문제점이 수면위로 그 몸통를 보여주기 시작한다.

이건 빙산의 일각일꺼란 생각이든다.

자,본격적으로 프로젝트 시작인거다.