update from, insert from . set은 from이 안들어감
Direct Updates - timescale
update를 중간부터 해버리면 rollback 이 안되기때문 ( DB commit 이 이루어지기 때문 check in이 되어버린다는 의미 ) 제일 마지막 모듈에서만 update를 진행
Direct Updates- Data Flow
마지막 dialog step에서 update를 하는게 all or nothing principle 을 구현하는 유일한 방법
Dicect UPdates - Locks
lock을 잡아서 하다가 마지막 step 에서 release를 하고 푸는 것
Perform on Commint - Timescale
perform 이라는 sub 뒤에 on commit 를 붙임.
기존에 perform changing 이나 using 을 사용했는데 on commit을 사용하면 commit work. ( explict 하게 commit) 하는 명령어를 만나면 수행을 안하다가 수행
호출은 여러번 될 수 있지만 수행은 한번만
subroutine으로 구현
PERFORM ON COMMit
error 메세지도 반드시 a로 , 그리고 반드시 roll back 사용금지
roll back 시키는 방법
1. message a
2 . message x
3. roll back work
poc 안에 들어가는 메세지 처리를 할 때 roll back , message x를 사용하면 안됨 ㄴㄴ
perform on commit
update technique sap가 만든 업데이트 테크닠 ..
summary
pros and cons -> 장단점
UPDATE Concept
다이얼로그 프로그램에서 업데이트 하려고 하는 목록들을 로그 파일에 만들어 두거나 request를 만들어 둠. request 끝났음 하면 box가
log가 쳐지는 역할을 하는게 commit work .
update 가 1~n개 까지 있을 때 그것들을 SAP LUW 라고 함.
여러가지 요구사항들을 header들을 붙여서 box sealing 을 한다고 생각하면 됨 하나의 LUW -> 를 업데이트 워크 프로세스로 던져넣음 
마무리 한 뒤 시스템에 보고
사용자가 처리하는 모든 프로그램을 다이얼로그 프로그램이라고 함
업데이트 테크닠을 사용하는 순서
write request -> LUW 를 만드는 작업
complete request -> commit work
function module을 사용해 디자인 ㄴ
-> 데이터 베이스 업데이트 코딩을 포함하는 update insert delete가 들어가 있는 호출
all or nothing transfer에 포함
지우는 것도 resource라고 생각하기 때문에 ...
2개의 모듈 얼터널티브, 펑션모듈
attribute창에 default로 펑션 노말이 되어있는데 마지막에 업데이트 모듈이 있음
그것이 바로.. DB업데이트를 하는데 사용되는 펑션모듈
exporting 이 없기 때문에 importing만 사용 message A <<
X나 roll back 은 펑션 모듈에 사용하면 안됨 . 무조건 메세지 A
why > export가 없어서 메세지를 받을 방법이 없음
classical data type -> 엘리머트, 스트럭처, 인터널 테이블
다이얼로그 프로그램에서는 commitment 사용가능 message a , roll back 가능
만약 펑션모듈에 들억갔다면 message A 만 사용해야함에 주의
프로세싱 페이지-> 업데이트 하는 단계. 업데이트 모듈을 만나면 로그를 다 지워버림
다이얼로그는 삽구이에서 워크프로세스가
업데이트 모듈은 upd가 처리. 쓸 수 있는 command 들이 정의되어 있는데
업데이트는 upd가 전담
roll back 등 command는 upd가 안들어가 있어서 안먹는 것
cpu가 가지고 있는 command 키가 있는데 upd는 안들어 있는 것
lock은 누가 처리하는지
사용자의 user request를 다이얼로그 프로그램 다이얼로그 워크프로세스가 처리
업데이트 워크 프로세스는 upd가 동작
scope=2 는 lock을 갖고 있다가 업데이트 모드로 들어가면 주도권을 넘겨주는 것
back exit save 끝났을 때 업데이트 테크닉을 쓰면 디큐안해도 알아서 함
마지막 업데이트 시 lock의 주도권을 upd 가 가지고 있다가 알아서 끝내는 것.
업데이트 테크닉 사용 시 인큐락만 사용 디큐락은 안써도 됨.
Asynchronous Update
vb 뭐시기는 데이터베이스 가끔 메모리에 저장 메모리는 어플리케이션 서버안에 이건 업데이트를 어떻게 하냐에 따라 저장되는 위치가 틀림
set update task local 은 사용안하는게 나음.
근데 책에 나와있어서 함 .
업데이트 프로세스가 없어지고 데이터베이스가 아니고 메인메모리에 로그테이블이 존재
로컬에서 작업하기 때문 ....트랜스페어런트 테이블이 없는 것 -> 트렌스 패어런트 테이블이 데이터베이스에 존재
io access .. 싱크로 억세스 언싱크로 억세스 보다는 빠름
일단 .. 데이터베이스가 물리적으로 데이터베이스에 실어야하는데 kbs처럼 대용량 데이터가 갈 수도 있기때문 .. 테이블을 밀어내야함으로 input output 이 ... 어플리케이션간 없기때문에 빨라 보이는데 ... 쓰지않는게 좋음..
v2는 v1이 업데이트 완료 후 실행되는 구성으로 할 수 있다.
v2는 항상 재실행 가능 v2는 v1과 연계 v1이 완료 시 commit이 됏는데 2가 에러된다면 roll back이 안되기 때문에 v2는 항상 재시작이 가능
collective run ... v1이 끝나면 2가 시작되게 하는 스페셜 타입 .
해당되는 리퀘스트는 v1 업데이트 후 바로 시작이 안되고 스케줄된 일정으로 정기적으로 업데이트 시키는 룰.
펑션 모듈을 디자인할 때 이미 v1, v2를 디자인. 실행 독립성을 가지고 있다는 것을 알 수 잇음 started delay 1이 끝나면 2를 실행
v1 디큐하고 2 는 락없이 진행함
set lock 을 걸고 dialog work 하고 commit work 시 upd에 lock 의 권한 끝나면 lock을 풀고 2는 lock 없이 업데이트. lock은 짧게 쳐야 함. v2는 하찮은 업데이트
일반적으로 락엔트리는 다이얼로그에서 지우고 락은 upd에서 지움 .
lock은 기본적으로 데이터를 수정하려는 목적이 강함. 단순히 보기만 한다고 해서 lock을 걸지는 않음..
사용자의 입력없고 사용자의 수정 없는 케이스에 사용
lock 자체가 필요없는 동작에 사용
Shortest Possible Database locks
lock을 optimize하려면 가장 긴거 기준으로 잡는다
poc- update 모듈안에 poc가 존재
업데이트 순서 - poc update 안에 poc가 또 존재
업데이트가 펑션 모듈 안에 poc. 순서의 독립성이 존재
se37 function builder : initail screen function module 분석 가능
펑션모듈 안은 업데이트 프롬없이 셋
back 은 work proccess 에서 하는 것
scope 2 로 되어있음을 확인
pai 200 dequeu all 을 지움 modify lock 컨트롤은 인큐 스코프 2에 upd 가 알아서 빼줌 . 정의되어있어서 알아서 lock을 빼준다는 의미
디버깅을 커밋에 눌러서 확인
프로그램 실행 cancel 누를 시
스트럭처로 받기 때문에 섭루틴에서 유징으로 받는 것
source code
