[SAP RAP] Behavior Definitions 에서 사용되는 구문들 정리

 

# ( features : instance ) 구문

 

BO 에서 자동으로 데이터를 생성/수정/삭제하는 로직을 연결해준다.

아래와 같이 선언해야한다.

create;

delete;

update;

 

 

그런데 옆에 ( features : instance ) 이런걸 선언할수도 있다.

사용하면 이렇게 -> create ( features : instance );

대부분 이건 Composition(부모-자식 관계) 구조에서 사용한다고 한다.

부모 – 과일

자식 – 레몬 , 사과

일 때 과일에서 싱싱하면 create 버튼을 누르고 상했다면 버튼을 비활성화 할 수있게 만들어줄수있다.

그냥 create 만 선언하면 계~~속 create 버튼이 활성화 되어있는거다.

 

# ( features : global );  구문

( features : instance ) 는 개별 데이터 (줄) 의 상태를 보고 활성화, 비활성화 시키는 거라면 features : global 은 이 사용자나 시스템 전체 상황에서 활성화,비활성화가 가능한지 판단하는 구문이다.

약간 instance 는 데이터 상태를 따라가고 global 은 권한 상태에 따라가는것같다.

 

예를 들어보면

delete ( features : instance );

줄마다 체크함. 1번 줄은 삭제 가능, 2번 줄은 삭제 불가.

 

delete ( features : global );

화면 전체를 체크함. 이 화면에 들어온 순간 모두 삭제 가능하거나, 모두 불가능하거나

 

 

# result [1] $self 구문

action ( features : instance ) apprReq result [1] $self ;

-> 결재 요청(apprReq) 같은 특정 동작을 수행하되, 버튼을 아무 때나 누르지 못하게 막겠다 라는 뜻

여기서 result [1] $self ; 이건 무슨뜻일까

이건 결과로 자기 자신의 데이터($self) 1건([1])을 다시 보여주겠다는 뜻이다.

 

그냥 action apprReq; 라고만 쓰면 365일 24시간 내내 결재 요청 버튼이 눌리게 된다.

이미 결재를 올린 건을 또 올리는 대참사를 막으려면 반드시 ( features : instance )를 붙여서 지금 이 데이터가 결재를 올릴 만한 상태인가?를 체크하는 로직이다.

 

# internal create; 구문

 

앞에 internal 이 붙을 때가 있더라.

이걸 사용하게 되면 외부 api 호출도 안되고 ui에서 사용도 불가능하다.

오직 같은 BO 내의 Action이나 Determination 등 이런 코드에서만 이 기능을 호출할 수

있다.

 

결론 !!

사용자가 직접 데이터를 생성하는 게 아니라, 시스템이 특정 조건일 때 자동으로 데이터를 만들어야 하는 경우에 사용한다.

 

예를 들어 결제 요청 액션 버튼을 누르게 되면 액션이 실행되면서 로그 데이터를 하나 생성해야한다.

여기서 사용자가 직접 입력해서 로그를 생성할 수는 없고 자동으로 로그가 생성되어야하기 때문에 internal 로 시스템이 자동 기록되게끔 만들어주는거다.

 

 

# Side Effect { }; 구문

 

side effects

  {

    field PurchaseOrg affects field Currency,

                              field PriceUnit,

                              field OrderPriceUnit,

                              field CurrentNetPrice,

                              field CurrentPriceUnit,

                              field StandardOrderQTy,

                              field MinimumOrderQTy,

                              field OrderUnit,

                              field Incoterms,

                              field IncotermsLocation;

}

PurchaseOrg 칸에 1000이라는 값을 넣으면 Side Effect 가 발생된다.

구매 조직이 바뀌면서 해당하는 (통화,단가 등..)필드들이 값을 채워주게된다.

 

이때 @ Semantics 랑 헷갈릴수있는데 이거랑 다르다

@Semantics (정적 설정): "내 짝꿍은 얘야!"라고 관계를 정의함. (화면 레이아웃 구성용)

Side Effects (동적 작동): "주인이 바뀌었으니 짝꿍 값을 다시 계산해와!"라고 동작을 명령함. (실시간 데이터 갱신용)

 

 

@Semantics.quantity.unitOfMeasure: 'ReqUnit'

      ReqQty,

      ReqUnit,

이렇게 쓰면 피오리 화면상 Quantity 에 대해 unit이 연결이 된다