모델을 실행한 후 이 오류 메시지를 본 적이 있다면 Mendix,이 게시물은 당신을위한 것입니다.

오류 메시지가 나타나는 데에는 여러 가지 이유가 있으며 메시지 변형도 여러 가지입니다. 이 게시물에서는 이러한 오류의 원인을 찾는 방법, 보다 일반적인 오류 중 일부를 수정하는 방법, 개발하는 동안 오류 가능성을 최소화하는 방법을 안내해 드리겠습니다.

게시물 전체에서 예시도 사용할 것입니다. 이러한 예시에 사용된 앱에는 Order, OrderLine, SaleOffer라는 세 개의 엔터티가 있습니다. 앱에서는 OrderLine을 Order에 추가하고 SaleOffer를 Order에 첨부할 수 있습니다.

근본 원인 찾기

오류가 발생하면 가장 먼저 오류가 발생한 위치를 찾아야 합니다.

앱이 로컬로 실행되는 경우:

Business Modeler를 열고 콘솔을 볼 수 있습니다. 콘솔 내에서 빨간색 'X'가 시작 부분에 있는 빨간색 줄 항목을 찾을 수 있습니다. 이 줄은 우리에게 필요한 정보를 제공합니다.

오류 메시지와 스택 추적에 대한 자세한 내용을 보려면 빨간색 선을 두 번 클릭하세요.

이 스택 추적에는 세 가지 주요 정보가 있습니다.

1. Microflow 이름 및 Microflow 오류 위치: 이 예에서 오류는 '숫자 > 0?' 캡션이 있는 배타적 분할(게이트웨이)의 'IVK_DeleteOrderLine'에서 발견되었습니다.
2. 발생한 오류: 이 예에서 오류는 java.lang.NullPointerException과 관련이 있습니다.
3. 실패한 정확한 표현이 경우, 실패는 널 포인터 예외를 발생시킨 배타적 분할 내의 조각과 관련이 있습니다.

앱이 클라우드 또는 서비스 콘솔에서 실행되는 경우

이 시나리오에서는 로그 파일에 액세스하여 오류 시간과 일치하는 타임스탬프가 있는 'ERROR'로 시작하는 줄을 찾아야 합니다. 필요한 모든 세부 정보는 로그에 순서대로 표시됩니다.

이제 오류 위치를 찾는 방법을 알았으니, 두 가지 흔한 오류와 이를 피하는 데 도움이 되는 몇 가지 패턴을 살펴보겠습니다.

널 포인터 오류

null 포인터 오류는 검색에서 반환된 객체가 없거나 객체의 속성이 비어 있을 때 발생합니다. 첫 번째 예에서 Microflow는 OrderLine을 삭제했지만 숫자가 0보다 큰지 확인했기 때문에 실패했습니다.

우리는 문제를 일으키는 배타적 분할을 확인합니다(앞서 언급한 (1) 항목). 이제 우리는 예외의 잠재적 원인을 알고 있으므로 문제 해결을 시작할 수 있습니다.

널 포인터 오류 수정 – 옵션 1:

Number 속성이 비어 있는지, 또는 OrderLine 개체가 비어 있는지 확인하는 검사를 추가합니다.

이러한 검사는 항상 필요한 것은 아닙니다. 객체가 비어 있을 수 없다면 비어 있는지 확인할 이유가 없습니다. '참'은 항상 수평으로 이어진다는 점에 유의하세요. 이는 모범 사례입니다.

이러한 검사는 하나의 배타적 분할로 수행할 수도 있습니다.

$주문라인 != 빈

$주문라인/숫자 != 빈

$주문라인/번호>0

기능적으로는 동일하지만, 분리된 분할은 Microflow를 읽고 이해하기 쉽게 만들 수 있습니다. 여기서 순서가 중요하다는 점에 유의하세요. 먼저 비어 있는 검사를 수행해야 하며, $OrderLine/Number>0을 평가하면 여전히 널 포인터 오류가 발생합니다.

널 포인터 오류 수정 – 옵션 2:

엔티티 검색이 비어 있는 경우 'GetCreate' 패턴을 구현해 보세요. 이 패턴은 Retrieve 작업 대신 Microflow 작업을 사용하여 구현됩니다. 이 예는 주문에서 SaleOffer를 업데이트하려고 하지만 아직 주문에 연결된 SaleOffer가 없는 경우 어떤 일이 발생하는지 보여줍니다.

이 인스턴스에서 GetCreate 패턴을 사용합니다. 단순히 SaleOffer를 검색하는 대신 SaleOffer를 반환하는 것이 보장된 Microflow를 호출합니다. 아래 Microflow는 이 패턴이 작동하는 방식을 보여줍니다.

Get Create 패턴의 첫 번째 단계는 SaleOffer를 가져오는(검색하는) 시도입니다. 이를 시도한 후 성공했는지 확인합니다. SaleOffer가 발견되면 이 SaleOffer를 반환합니다. 검색이 실패하면 새 SaleOffer를 생성하여 주문에 연결합니다. 이렇게 하면 다음에 이 Microflow가 호출될 때 검색이 성공합니다. 마지막으로 NewSaleOffer를 반환합니다.

이 패턴은 객체의 새 인스턴스를 만드는 것이 안전할 때만 구현해야 합니다. 상황에 따라 항상 그렇게 하는 것이 적절하지 않을 수 있습니다. 그런 경우에는 단순히 empty 검사를 수행하고 그에 따라 진행해야 합니다.

보안 오류

보안은 모든 도메인 모델, Microflow 및 페이지 내에서 중요한 구성 요소입니다. 그러나 보안을 활성화하여 테스트할 때 '보안상의 이유로 실패했습니다.'라는 문구가 있는 오류 메시지가 표시될 수 있습니다. 가장 일반적인 보안 오류 중 하나는 엔터티 액세스와 관련이 있습니다.

엔티티 액세스 적용 Microflow의 속성에 있는 설정입니다. 엔티티 액세스가 적용되는지 확인하는 가장 빠른 방법은 Microflow의 배경색을 확인하는 것입니다. 엔티티 액세스가 적용되면 Microflow에 약간의 색조가 생깁니다.

위의 예에서 오른쪽에 표시된 Microflow에는 엔티티 액세스가 적용되었습니다. 엔티티 액세스가 적용되면 엔티티에 설정된 보안이 Microflow 액세스보다 우선합니다.

이 예시의 목적을 위해 '사용자'와 '관리자'라는 두 개의 사용자 역할과 '사용자'와 '관리자'라는 두 개의 모듈 역할이 있다고 가정해 보겠습니다. '사용자'는 '사용자' 모듈 역할에 매핑되고, '관리자'에 대한 유사한 구성이 있습니다.

보안 오류를 조사할 때는 이전과 동일한 단계를 따릅니다. 즉, 콘솔로 가서 빨간색으로 강조 표시된 정보를 찾아 오류를 일으킨 작업으로 이동합니다. 예를 들어, 오류가 여기에서 발생하고 있음을 알게 됩니다.

이 Microflow에 엔티티 액세스가 적용되어 있음을 알 수 있습니다(배경 색조로). 따라서 엔티티와 Microflow의 보안을 확인해야 합니다. Microflow는 사용자 역할이 '관리자'이고 엔티티 SaleOffer에 다음 보안 설정이 있는 사용자가 액세스할 수 있습니다.

여기서 문제가 식별됩니다. '관리자'가 Microflow에서 SaleOffer 엔터티를 만들려고 하지만 그렇게 할 권한이 없습니다. 이를 해결하는 방법은 두 가지가 있지만 적절한 솔루션은 특정 사용 사례에 따라 달라집니다.

1. '관리자' 모듈 역할에 SaleOffer 생성 권한을 추가합니다.
2. '관리자'가 Microflow에 액세스할 수 없도록 설정

다음은 발생할 수 있는 런타임 오류의 몇 가지 예입니다. 자주 발생하는 다른 오류도 있나요? 어렵거나 혼란스러운 오류는 있나요?