Sub-Microflows

학습 목표

이 모듈을 마치면 다음을 수행할 수 있습니다.

• 서브 마이크로플로우를 사용하세요
• 서브 마이크로흐름 (재)사용성 최적화
• 규칙을 사용하여 결정의 재사용성을 개선하세요

---

Mendix Intermediate Course 에서 우리는 검증 로직을 별도의 마이크로플로로 추출하기 위해 서브 마이크로플로를 사용했습니다. 서브 마이크로플로를 사용하면 마이크로플로의 가독성을 개선하는 데 도움이 되며, 이는 서브 마이크로플로를 사용하는 주요 이유 중 하나입니다. 다른 이유는 로직을 재사용하고 유지 관리를 개선하기 위한 것입니다.

Create Sub-Microflows

많은 마이크로플로에서 특정 객체를 검색하거나 객체가 없는 경우 객체를 만드는 것으로 시작합니다. 이를 "get-or-create" 마이크로플로라고 합니다.

[ 그림 1 ]

 

 

하위 마이크로흐름을 사용할 수 있으므로 Account 또는 NewAccount 개체를 전달하는지 여부에 따라 페이지를 여는 데 두 가지 별도의 작업을 사용할 필요가 없습니다.

[ 그림 2 ]

[ 그림 3 ]

재사용성 최적화

서브 마이크로플로를 사용하는 주된 이유 중 하나는 이미 만든 로직을 재사용할 수 있다는 것입니다. 쉽게 재사용할 수 있는 서브 마이크로플로를 만들려면 몇 가지 중요한 영역에 주의해야 합니다.

단일 기능

마이크로플로우의 재사용성은 포함된 기능이 독립형 논리 조각일 때 향상됩니다. 마이크로플로우에서 여러 기능을 결합하면 재사용성이 감소합니다. 애플리케이션의 다른 곳에서 해당 마이크로플로우의 한 부분만 사용하고 싶을 수 있습니다.

 

 가장 좋은 방법은 메인 흐름에서 데이터를 구성하여 가능한 한 많은 것을 검색하거나 생성하고 서브 마이크로흐름으로 전달하는 것입니다. 이렇게 하면 다음이 보장됩니다.

• 하위 마이크로흐름의 호출자는 하위 마이크로흐름에서 검색 작업에 의존하는 대신 전달된 객체를 완전히 제어합니다.
• 데이터를 두 번 검색하는 일이 방지됩니다.

서브 마이크로플로우 내부 또는 외부에서 커밋

이 이론 단원은 하위 마이크로플로가 단일 함수를 실행해야 한다는 말로 시작했습니다. 이를 염두에 두고, 메인 마이크로플로에서 사용 가능한 객체나 목록은 여러 하위 마이크로플로에서 사용될 수 있다고 추론할 수 있습니다. 따라서 하위 마이크로플로에서 객체나 목록에 대한 변경 사항을 직접 커밋하면 동일한 객체나 목록에 대한 여러 커밋이 발생할 수 있습니다. 따라서 하위 마이크로플로 내부에서 객체나 목록을 커밋하지 않고 대신 메인 마이크로플로의 끝에서 커밋하는 것이 좋습니다. 이렇게 하면 객체가 커밋될 때 메인 마이크로플로가 제어됩니다.

 

그 반대도 사실일 수 있습니다. 예를 들어, 하위 마이크로플로가 이메일을 보내고 이메일도 애플리케이션의 데이터베이스에 저장됩니다. 이메일 객체와 그 데이터는 하위 마이크로플로에서 생성되고 이 이메일 객체는 주 마이크로플로에서 사용할 수 없거나 사용되지 않습니다. 그런 경우 하위 마이크로플로에서 커밋하는 것이 더 합리적이며 그렇게 하는 것이 좋습니다.

 

결론은 다음과 같습니다.

• 메인 마이크로플로에서 사용할 수 있는 객체/목록이 입력 매개변수로 전달되는 경우 하위 마이크로플로에서 커밋하지 말고, 메인 마이크로플로에서만 커밋하세요.
• 하위 마이크로흐름에서 생성되거나 검색되었지만 출력 매개변수로 전달되지 않은 객체/목록의 경우 하위 마이크로흐름에서 커밋을 수행합니다.

 

서브 마이크로플로우 사용 개선 Part 1

ACT_Customer_UpgradeStatus_1

워크스루

ACT_Customer_UpgradeStatus_1 마이크로플로에는 5년 이상 활동한 모든 고객을 반복하는 루프가 포함되어 있습니다. 이 루프는 SUB_Customer_ChangeStatus_1 하위 마이크로플로를 호출 합니다.

[ 그림 4 ]

언뜻 보기에 이 microflow 에는 아무런 문제가 없는 것처럼 보입니다. 따라서 이 microflow 보다 sub-microflow 을 자세히 살펴보겠습니다.

[ 그림 5 ]

고객의 모든 주문을 검색하고 모든 주문의 총 가치가 $3,000 이상인지 확인합니다. 그렇다면 고객의 상태가 Platinum 으로 업그레이드됩니다 . 이 변경 사항은 데이터베이스에 즉시 커밋되고 클라이언트가 새로 고쳐집니다.

 

하지만 회사에 1,000명 이상의 고객과 같은 대규모 고객 기반이 있다면 어떻게 될까요? 그러면 이 하위 마이크로플로는 잠재적으로 1,000회 이상 트리거될 수 있습니다. 클라이언트를 1,000회 이상 연결, 커밋, 새로 고침하면 큰 속도 저하가 발생할 수 있습니다!

 

그러면 이 상황을 어떻게 개선할 수 있을까요? 하위 마이크로플로에서 Customer 객체를 변경 하고 메인 마이크로플로에서 모든 Customer 객체를 한 번에 커밋하면 됩니다. 클라이언트를 한 번만 새로 고침하면 됩니다.

 

메인 마이크로플로에서 Commit 활동은 CustomerList가 데이터베이스에 커밋되고 클라이언트가 새로 고쳐지 는 루프 바로 뒤에 메인 마이크로플로에 추가됩니다 . 이 두 가지 동작은 이제 여러 번이 아니라 한 번만 발생합니다. 결과는 다음과 같습니다.

[ 그림 6 ]

 

하위 마이크로흐름에서 하위 마이크로흐름 내의 Change Object 활동이 변경되었고, 클라이언트의 Commit 과 Refresh가 모두 No 로 설정되었습니다 .

[ 그림 7 ]

변경된 고객만 포함하는 새 목록을 만들고 해당 목록을 데이터베이스에 커밋하면 이 마이크로플로를 더욱 개선할 수 있습니다. 이렇게 하면 변경되지 않은 객체의 불필요한 커밋을 방지할 수 있습니다.

 

하지만 만약 객체를 반환한다면?

[ 그림 8 ]

Customer 객체가 변경되지 않으면 반환 변수는 Customer 유형 이지만 값은 비어 있습니다. 이제 메인 마이크로플로우의 루프 내부에 Add to List 활동을 추가하기만 하면 됩니다 .

 

여기서 새로 만든 목록과 루프에서 목록에 추가 활동이 있는 주요 마이크로플로를 볼 수 있습니다 . 여기서 하위 마이크로플로의 반환 변수가 목록에 추가됩니다. 따라서 이제 변경된 고객만 CustomerList_UpdatedCustomers 목록에 추가되고 데이터베이스에 커밋됩니다!

[ 그림 9 ]

• 커밋 활동을 루프 안에 넣지 마세요 . 그러면 애플리케이션 속도가 크게 떨어질 수 있습니다. 루프 안에서 서브 마이크로플로를 사용할 때는 항상 이 점을 명심하세요.

서브 마이크로플로우 사용 개선 Part 2

ACT_Customer_UpgradeStatus_2

여기의 기능은 위의 1부 마이크로플로와 거의 같습니다. 그러나 사소한 차이점이 하나 있습니다. 고객의 상태는 항상 "골드" 또는 "플래티넘"으로 변경됩니다.

[ 그림 10 ]

ACT_Customer_UpgradeStatus_2 마이크로플로는 이전 과제의 마지막 개선을 위한 마이크로 플로와 동일합니다. 이 마이크로플로에서 새로 생성된 목록과 반환 변수는 하위 마이크로플로에서 변경된 객체만 커밋하는 데 사용됩니다.

 

하지만, 서브마이크로플로우를 자세히 살펴보면, 그 기능이 첫 번째 과제의 기능과 다르다는 것을 알 수 있습니다. 회사에서 규칙을 변경했기 때문입니다! 이전에는 고객의 상태가 5년 이상 활성 고객이었고, 모든 주문의 합산 가치가 3,000달러를 초과하는 경우에만 변경되었습니다. 두 가지 요구 사항을 모두 충족하는 경우, 그들의 상태는 플래티넘 으로 변경되었습니다 .

SUB_Customer_ChangeStatus_2 하위 마이크로흐름 에서 이 새로운 규칙을 확인할 수 있습니다. 고객이 5년 이상 활동했지만 총 주문 가치가 3,000달러를 넘지 않으면 골드 상태로 승격됩니다.

[ 그림 11 ]

그럼 여기서 실수는 무엇일까요? 하위 마이크로플로가 이제 항상 Customer 객체를 변경하기 때문에 반환 변수를 사용할 필요가 없습니다! 객체는 메모리에서 변경되고 마이크로플로의 전체 범위에서 사용할 수 있습니다. 변경된 객체를 메인 마이크로플로로 다시 전달할 필요가 없으며, 변경된 객체만 커밋하기 위해 추가 목록을 사용하는 것은 더 이상 의미가 없습니다. 이 목록은 데이터베이스에서 검색된 목록과 동일하기 때문입니다.

[ 그림 12 ]

create list 및 add to list 활동이 제거되었고 Commit 활동은 전체 CustomerList를 커밋합니다 . 하위 마이크로플로는 더 이상 반환 값을 사용하지 않습니다.

[ 그림 13 ]

 

• 하위 마이크로흐름에서 검색, 생성 또는 생성된 새 데이터에 대해서만 반환 값을 사용합니다.

서브 마이크로플로우 사용 개선 Part 3

ACT_CommitOrder

[ 그림 14 ]

개선할 수 있는 두 가지 가능성이 있습니다. 첫째, SUB_DetermineOrderNumber 마이크로플로를 엽니다.

[ 그림 15 ]

 

하위 마이크로플로가 Customer 엔터티 를 검색한다는 점에 유의하세요 . 지금 메인 마이크로플로로 돌아가면 Customer 객체가 이미 여기에서 입력 매개변수로 사용 가능하다는 것을 알 수 있습니다. 이렇게 되면 하위 마이크로플로에서 검색이 불필요해집니다.

 

하위 마이크로흐름은 검색 활동을 제거하고 고객 개체 에 대한 두 번째 입력 매개변수를 추가하면 개선될 수 있습니다 .

[ 그림 16 ]

 

메인 마이크로플로에서 Call Microflow 활동 의 설정을 업데이트해야 한다는 점을 명심하세요 .

 

두 번째 개선 사항은 sub-microflow SUB_GetOrderLineForDiscount를 엽니다.

[ 그림 17 ]

이 하위 마이크로플로의 첫 번째 활동은 OrderLine 엔터티 에서 검색하는 것 입니다 . 메인 마이크로플로로 돌아가서 이 마이크로플로에도 OrderLine 엔터티에서 검색이 포함되어 있음을 확인합니다. 이제 하위 마이크로플로에서 불필요한 검색 작업을 하나 더 식별했습니다. 그렇다면 여기서 가장 좋은 조치는 무엇일까요?

 

먼저, 메인 마이크로플로우에서 검색 활동을 SUB_GetOrderLineForDiscount 마이크로플로우가 호출되는 호출 마이크로플로우 활동 앞 지점으로 이동합니다 .

[ 그림 18 ]

다음으로, SUB_GetOrderLineForDiscount 마이크로플로를 열고 검색 활동을 제거합니다 . 그런 다음, OrderLine 엔터티 에 대한 목록 데이터 유형이 있는 입력 매개변수를 추가합니다 .

[ 그림 19 ]

 

메인 마이크로플로에서 Call Microflow 활동 의 설정을 업데이트

• 하위 마이크로흐름에서 불필요한 검색을 피하세요. 주 마이크로흐름에서 객체나 변수를 사용할 수 있는 경우, 이를 입력 매개변수로 하위 마이크로흐름에 전달하세요.

 

 

Rules

이 학습 단원에서는 규칙을 서브 마이크로플로우의 대안으로 살펴보겠습니다. 서브 마이크로플로우를 사용하여 개별 조건이나 조건 집합을 확인할 때마다 규칙을 사용하여 이를 수행할 수도 있습니다.

 

규칙은 일반 마이크로플로우와 정확히 비슷해 보이지만 항상 부울 또는 열거형의 반환 값을 갖습니다.
규칙은 속성에 특정 값이 있는지 또는 필수 연결이 생성되었는지 확인할 수 있습니다.

규칙은 다음 작업을 수행할 수 없습니다.

• 데이터베이스의 데이터 변경 - 객체 생성, 삭제, 변경, 롤백 및 커밋 작업은 규칙에서 사용할 수 없습니다.
• 클라이언트와의 상호작용 수행 - 양식 표시 또는 닫기, 메시지 표시, 검증 피드백 보내기, 파일 다운로드 작업은 규칙에서 사용할 수 없습니다.
• 웹 서비스 호출
• 문서 생성
• XML 가져오기

  

  [ 그림 20 ]

규칙 사용의 이점

결정에서 직접 규칙을 사용하고 규칙의 결과를 결정에서 다른 종료 흐름으로 사용할 수 있습니다. 따라서 먼저 하위 마이크로플로를 호출하고 해당 하위 마이크로플로의 반환 변수를 결정에서 사용하는 대신 조건을 확인하고 즉시 다른 경로를 만들 수 있습니다.

다음은 결정에 따른 sub-microflow가 있는 마이크로흐름의 예입니다.

[ 그림 21 ]

다음은 동일한 마이크로흐름이지만, 하위 마이크로흐름을 사용하는 대신 규칙을 사용하여 조건을 확인합니다.

[ 그림 22 ]

이것은 작은 차이이지만, 마이크로플로우의 가독성을 향상시킵니다.

 

규칙 사용

ACT_Customer_UpgradeStatus_3

[ 그림 23 ]

CheckUpgradeToPlatinumStatus라는 이름의 규칙을 만들어서 정확히 같은 동작을 하게 구현하세요. 기억하세요: 규칙은 결정에서 구현됩니다!

 

 SUB_Customer_ChangeStatus_3 

 고객이 "플래티넘" 상태로 업그레이드하기 위한 총 주문 가치 요구 사항을 충족하는지 확인하고 부울 값을 반환합니다.

[ 그림 24 ]

RULE_CheckUpgradeToPlatinumStatus 생성

SUB_Customer_ChangeStatus_3 와 동일 하게 제합니다.

[ 그림 25 ]

 

규칙을 구현해 보겠습니다. ACT_Customer_UpgradeStatus_3 마이크로플로로 이동하여 루프에서 Call Microflow 활동을 제거합니다 . Set to platinum? 결정을 열고 표현식 대신 규칙을 선택하고 다음 설정을 사용합니다.

 

이제 마이크로플로우는 다음과 같아야 합니다.

[ 그림 26 ]

 

출처 : https://academy.mendix.com/link/paths/6/Master-Modeling-Microflows