exit 을 어떻게 찾는지 clssic bodi/ new bodi에 어디있는지 찾는것이 핵심
screen painter에서 화면을 만드 때 sementic을 가져오기 위해 screen에서 만들 때 화면에 보이는 글자는 domain,등이 어떤 곳에
데이터 엘레멘트에 필드레벨 적을 때 short, long, heading
modification위험을 감수하고 사용자가 sap standard가 만들어놨다면 그걸보고 사용자가 enhancement를 할 수 있음 -> standard수정
사용자가 자기 목적에 맞게 자기 모양대로 디자인 하는 프로그램은 모두 customer programs에 해당한다는 것
특히 sap standard는 그대로 쓰면되는데 한국특성상 customer programs를 사용하려는 경향이 강함
customizing 개발과는 상관 없음
repository 는 database layer에 있음
Procedure for Deciding how to make changes
new bodi는 명시적, 암묵적인 enhancement가 같이 들어가 있음.
documnet - function code라고 알 수 있음
메뉴에 logic을 추가해야한다.
standard 를 보면 screen exit 이 있고 수정해야할 필요성을 볼 수 있음 - > screen을 만들어야 함
subscreen 잡고 logic 잡고 document를 바꾸고 customer exit 은 body 는 oop로 만들어져 있음
user exit - > customer eixt으로 발전되면서 다양한 기능들이 수행가능하게 되었음.
각 나라마다 로그인 렝귀지에 다른 멀티플 인플레이션을 제공하는 것이 filter body.
사용자의 요청에 따라 자동으로 body가 바뀌어서 나오는 것
exercise에서는 filter body는 안 할 예정
body는 프로그램의 멀티플 엑싯을 통해서 파트너들에게 주든 .. custom에 주던 여러가지 인플리테이션을 제공
new body 형태로 많이 빠지다보니 과거의 형태는 보기 힘들 수 있음
enhancement 의 특징
명시적, 암묵적인 내용
펑션모듈과 메서드 . export , changing . 등 말하지 않아도 추가적으로 만들 수 있음. class에 sap standard method 와 attributes를 추가할 수 있지만 중간이 아닌 제일 뒤에 추가해야 함
classic body, new body에 있어서 명시적으로 찾아야 하는게 핵심
enhancement는 만드는것보다 찾는것이 더 중요 .
new body. classic ==> function module 이 있으면 모두 추가 가능
global sap method 를 위한 sap method 안에 main method가 동작하는 이전에 동작하는것을 premethod로 설정할 수 있음. 다음에 동작하라고 postmethod도 지정할 수 있음 -> exit이 없어라도 묻지않고 바로 실행
nomal method , replace (제한조건이 있지만 가능)
subroutine 이 들어가 있을 수도 있지만 subroutine 안에 들어가는 parameter나 logic은 제일 뒤에 추가할 수 있음 ( 암묵적으로 )
enhancement category . append structure 업그레이드
context 는 전반적인 이해. exit을 만들어 둔 이유.
어떻게 연결되어있는지는 smod에 들어가서 document를 읽어봐야 함
보통 smod로 가지고 작업 구현하는데 목적이 있지만
실무에서는 smod가 어디로 연결되어있는지, 화면과 연결된 global variable 을 찾는게 어려움. -> smod를 눌러서 exit을 읽어봐야 한다는 점
context와 text를 이해
smod 는 sap에 대한 정보
cmod는 그 컨텍스트를 이해하고 고쳐나가는 차이점이 있음
smod는 definition sap 의 enhancement에 대한 정의가
cmod는 정의긴하지만 어떤 enhancement를 나열하고 내부적으로 고쳐들어가는 것
enhancements and enhancement projects
enhancement의 프로젝트를 만들고 어트리뷰트를 정의 ( 디스트리뷰트, 네임스페이스 정보 등) 한 다음 어떤 인헨스먼트를 하겠다 ( 로직, 메뉴, 프로그램 ) 등에 대해 정의 - > 이 정보는 smod에 존재
cmod를 통해서 여러가지 등을 내가 만들어서 정의하는 것
정보는 smod에 존재
서로 상호작용을 하며 프로그램을 만들어야 함
smod 분석이 끝난 뒤 펑션모듈 로직을 할 지 메뉴, 스크린을 할지 smod를 통해 파악을 한 뒤에 sap enhancement의 번호를 따고 로직코드를 정의하고 디자인, activation, documenetation을 남기고 과정이 종료 
smod가 다 끝난 뒤 cmod를 누르면 
나오는 화면
creation 을 누르면 attributes창이 나오고 그러면 만든 화면이 나오고 short description 을누르고 저장을 누르고 어떻게 할 지
sap 의 exit이 존재한다는 가정하에 보는 것
enhancement 도 이관의 대상
change request 번호를 일단 잘 따서 다른 QA장비로 넘길 수 있음.
enhancement프로그램 전체를 딸 수 있음.
exit function module의 이름을 알면 include 파일을 더블클릭해서 forward . 코드를 치면 되는 방식
sap standard finder를 통해서 찾게되면 번호를 더블클릭 펑션모듈로 자동으로 넘어가는데 function end function. exit으로 시작해서 001로 붙어 있음
코드는 인클르두 문을 포워딩 해서 그 안에서 작성하는 것
global search RIS 에서 찾을 수도 있고 implementation guide line 서치를 통해서 document를 확인해서 찾을 수도 있으며 또는 어떤 프로그램 내에서 system - status창을 찾아서 프로그램 더블클릭- 파인더에서 call customer등을 통해서 또는
cmod-> utilities 에서 찾을 수 있음
가장 많이 찾는 방법은 system -> status -> double click -->
왜냐면 sap 프로그램을 운영하면서 어떤 프로그램을 고쳐야하는지 알고 있으며 status에서 프로그램이름을 가장 쉽게 찾을 수 있기 때문에 프로그램 이름을 찾기 제일 쉬움.
naming space를 설명하고 각각의 include문만을 보면
어떤 내용이 들어가야하는지 이해해야 함 ...
enhancement와 관련된 펑션모듈이 필요 .
인클루드 문안에서 소스코드를 코딩해야하기 때문에
exit은 노말과 비교해서 조금 더 나뉘어져 있음 
top , Uxx, F00
lx로 되어있음 exit function 그룹이고
UXX 는 원래 01밖에 없는데 enhancement를 한것은 z로 확장되어 있음
사용자가 enhancement를 했을 때 만들어짐 
밑에서 하위에서 쓰는 데이터들은 top 위에 올려야 한다는 것 
사용자가 만든 것들은 아래 연두색
스크린 exit만들 때 이야기
스탠다드능 exit module 이 어떻게 작동하는지
call customer function 을 찾고 더블클릭하면 function exit 모듈로 가고 그 안에 include z xx 첫번째 엑신 모듈에 대한 사용자의 정의 값 call screen 9000 을 만들어주면 화면을 통해서 9000의 pbo pai를 수행하고 아래 주욱 수행 한뒤 다시 프로그램으로 던져줌
9000번에 9100 번의 화면이 필요한다고 하면 내부적으로 프로그램을 만들어 줄 수 있다는 것 => screen exit이 아님
원래는 간단학 써주고 복잡하게 써주지 않음
망원경 모양으로 call customer function 을 찾아줌
RIS 
메세지 클래스 넣어주기
입력받은 세개의 입려값을 넣어주기
sap 할당해놓은 subscreen 영역에다가 사용자가 imbeding시키겠다는것
화면을 넣는것보다 subscreen에서 data transfer가 중요.
PBO _ PAI for subscreen 영역을 적으면 nomal subscreen 영역이 출력되는 것
call customer-subscreen 을 찾아서 보면 빈영역
여기에 만든 프로그램을 끼워넣으면 되는 것
호출할 때는 메인프로그램이 짜져 있기 때문에
사이즈까지 잡혀있기때문에 subscreen 번호를 만들어놓고 끼워놓을 필요가 있음.
결국 데이터 트랜스퍼가 핵심
data transfer를 어떻게 할 지 설명
screen logic과 abap logic이 나눠져 있음
flow logic에 있어서는 call subscreen 할당된 영역이 있다는 것을 먼저 확인
system 안에서 finder를 통해서 call subscreen -> screen painter 를 통해 진짜로 그 영역이 있는지 확인
당연히 데이터를 컨트롤 하는 call customer function 도 존재
smod document가 context설명을 한다는 것
사용자가 입력을 하면 데이터를 순환시키는 구현하는게 필요
