MuleSoft-퀵 가이드

ESB는 Enterprise Service Bus이것은 기본적으로 버스와 같은 인프라를 통해 다양한 애플리케이션을 통합하기위한 미들웨어 도구입니다. 기본적으로 통합 애플리케이션간에 작업을 이동하는 일관된 수단을 제공하도록 설계된 아키텍처입니다. 이러한 방식으로 ESB 아키텍처의 도움으로 통신 버스를 통해 서로 다른 애플리케이션을 연결하고 서로 의존하지 않고 통신 할 수 있습니다.

ESB 구현

ESB 아키텍처의 주요 초점은 시스템을 서로 분리하여 안정적이고 제어 가능한 방식으로 통신 할 수 있도록하는 것입니다. ESB의 구현은 다음을 통해 수행 할 수 있습니다.‘Bus’ 과 ‘Adapter’ 다음과 같이-

• JMS 또는 AMQP와 같은 메시징 서버를 통해 달성되는 "버스"개념은 서로 다른 응용 프로그램을 서로 분리하는 데 사용됩니다.

• 백엔드 애플리케이션과 통신하고 애플리케이션 형식에서 버스 형식으로 데이터를 변환하는 책임이있는 "어댑터"개념은 애플리케이션과 버스간에 사용됩니다.

버스를 통해 한 애플리케이션에서 다른 애플리케이션으로 전달되는 데이터 또는 메시지는 하나의 일관된 메시지 형식이 있음을 의미하는 표준 형식입니다.

어댑터는 보안, 모니터링, 오류 처리 및 메시지 라우팅 관리와 같은 다른 활동도 수행 할 수 있습니다.

ESB의 기본 원칙

이러한 원칙을 핵심 통합 원칙이라고 부를 수 있습니다. 그들은 다음과 같습니다-

• Orchestration − 데이터와 프로세스 간의 동기화를 달성하기위한 둘 이상의 서비스 통합.

• Transformation − 표준 형식에서 응용 프로그램 별 형식으로 데이터 변환.

• Transportation − FTP, HTTP, JMS 등과 같은 형식 간의 프로토콜 협상 처리

• Mediation − 여러 버전의 서비스를 지원하기 위해 여러 인터페이스를 제공합니다.

• Non-functional consistency − 거래 및 보안 관리를위한 메커니즘도 제공합니다.

ESB의 필요성

ESB 아키텍처를 통해 각 애플리케이션이 통신 할 수있는 여러 애플리케이션을 통합 할 수 있습니다. 다음은 ESB 사용시기에 대한 몇 가지 지침입니다.

• Integrating two or more applications − ESB 아키텍처를 사용하면 둘 이상의 서비스 또는 애플리케이션을 통합해야 할 때 유용합니다.

• Integration of more applications in future − 향후 더 많은 서비스 또는 애플리케이션을 추가하려는 경우 ESB 아키텍처의 도움으로 쉽게 수행 할 수 있습니다.

• Using multiple protocols − HTTP, FTP, JMS 등과 같은 여러 프로토콜을 사용해야하는 경우 ESB가 올바른 옵션입니다.

• Message routing − 메시지 내용 및 기타 유사한 매개 변수를 기반으로 메시지 라우팅이 필요한 경우 ESB를 사용할 수 있습니다.

• Composition and consumption − 구성 및 소비를 위해 서비스를 게시해야하는 경우 ESB를 사용할 수 있습니다.

P2P 통합 vs. ESB 통합

응용 프로그램 수가 증가함에 따라 개발자들에게 가장 큰 질문은 다른 응용 프로그램을 연결하는 방법이었습니다. 상황은 다양한 애플리케이션 간의 연결을 직접 코딩하여 처리했습니다. 이것은 ... 불리운다point-to-point integration.

Rigidity점대 점 통합의 가장 명백한 단점입니다. 연결 및 인터페이스 수가 증가함에 따라 복잡성이 증가합니다. P-2-P 통합의 단점은 ESB 통합으로 이어집니다.

ESB는 애플리케이션 통합에 대한보다 유연한 접근 방식입니다. 각 애플리케이션 기능을 개별 재사용 가능한 기능 세트로 캡슐화하고 노출합니다. 응용 프로그램은 다른 응용 프로그램과 직접 통합되지 않으며 대신 아래와 같이 ESB를 통해 통합됩니다.

통합 관리를 위해 ESB에는 다음 두 가지 구성 요소가 있습니다.

• Service Registry− Mule ESB에는 ESB에 노출 된 모든 서비스가 게시되고 등록되는 Service Registry / Repository가 있습니다. 다른 애플리케이션의 서비스와 기능을 사용할 수있는 검색 지점 역할을합니다.

• Centralized Administration − 이름에서 알 수 있듯이 ESB 내부에서 발생하는 상호 작용 성능의 트랜잭션 흐름에 대한보기를 제공합니다.

ESB Functionality− VETRO 약어는 일반적으로 ESB의 기능을 요약하는 데 사용됩니다. 다음과 같습니다-

• V(Validate)-이름에서 알 수 있듯이 스키마 유효성을 검사합니다. 유효성 검사 구문 분석기와 최신 스키마가 필요합니다. 한 가지 예는 최신 스키마를 확인하는 XML 문서입니다.

• E(Enrich)-메시지에 추가 데이터를 추가합니다. 목적은 메시지를 대상 서비스에 더 의미 있고 유용하게 만드는 것입니다.

• T(변환)-데이터 구조를 표준 형식 또는 표준 형식으로 변환합니다. 예를 들면 날짜 / 시간, 통화 등의 변환이 있습니다.

• R(라우팅)-메시지를 라우팅하고 서비스 엔드 포인트의 게이트 키퍼 역할을합니다.

• O(Operate) −이 기능의 주요 작업은 대상 서비스를 호출하거나 대상 앱과 상호 작용하는 것입니다. 백엔드에서 실행됩니다.

VETRO 패턴은 통합에 대한 전반적인 유연성을 제공하고 일관되고 검증 된 데이터 만 ESB 전체에 라우팅되도록합니다.

Mule ESB 란 무엇입니까?

Mule ESB는 MuleSoft에서 제공하는 가볍고 확장 성이 뛰어난 Java 기반 ESB (Enterprise Service Bus) 및 통합 플랫폼입니다. Mule ESB를 사용하면 개발자가 애플리케이션을 쉽고 빠르게 연결할 수 있습니다. 응용 프로그램에서 사용하는 다양한 기술에 관계없이 Mule ESB를 사용하면 응용 프로그램을 쉽게 통합하여 데이터를 교환 할 수 있습니다. Mule ESB에는 다음 두 가지 버전이 있습니다.

• 커뮤니티 에디션
• 기업용 에디션

Mule ESB의 장점은 두 버전 모두 공통 코드 기반에 구축 되었기 때문에 Mule ESB 커뮤니티에서 Mule ESB 엔터프라이즈로 쉽게 업그레이드 할 수 있다는 것입니다.

Mule ESB의 특징 및 기능

다음 기능은 Mule ESB가 보유하고 있습니다-

• 간단한 드래그 앤 드롭 그래픽 디자인이 있습니다.
• Mule ESB는 시각적 데이터 매핑 및 변환이 가능합니다.
• 사용자는 사전 제작 된 인증 커넥터 100 개를 확보 할 수 있습니다.
• 중앙 집중식 모니터링 및 관리.
• 강력한 엔터프라이즈 보안 시행 기능을 제공합니다.
• API 관리 기능을 제공합니다.
• 클라우드 / 온 프레미스 연결을위한 보안 데이터 게이트웨이가 있습니다.
• ESB에 노출 된 모든 서비스가 게시되고 등록되는 서비스 레지스트리를 제공합니다.
• 사용자는 웹 기반 관리 콘솔을 통해 제어 할 수 있습니다.
• 서비스 흐름 분석기를 사용하여 신속한 디버깅을 수행 할 수 있습니다.

Mule 프로젝트의 동기는 다음과 같습니다.

• 프로그래머를 위해 일을 더 간단하게 만들기 위해

• 애플리케이션 수준 메시징 프레임 워크에서 전사적으로 분산 가능한 프레임 워크로 확장 할 수있는 경량 및 모듈 식 솔루션의 필요성.

Mule ESB는 이벤트 기반 및 프로그래밍 프레임 워크로 설계되었습니다. 메시지의 통합 표현과 결합되고 플러그 형 모듈로 확장 할 수 있기 때문에 이벤트 기반입니다. 프로그래머가 특정 메시지 처리 또는 사용자 지정 데이터 변환과 같은 일부 추가 동작을 쉽게 이식 할 수 있기 때문에 프로그래밍 방식입니다.

역사

Mule 프로젝트의 역사적 관점은 다음과 같습니다.

SourceForge 프로젝트

Mule 프로젝트는 2003 년 4 월 SourceForge 프로젝트로 시작되었으며 2 년 후 첫 번째 버전이 출시되어 CodeHaus로 옮겨졌습니다. UMO (Universal Message Object) API는 아키텍처의 핵심이었습니다. UMO API이면의 아이디어는 로직을 통합하면서 기본 전송에서 격리하는 것이 었습니다.

버전 1.0

2005 년 4 월에 수많은 수송을 포함하여 출시되었습니다. 그 뒤를 잇는 다른 많은 버전의 주요 초점은 디버깅 및 새로운 기능 추가였습니다.

버전 2.0 (Spring 2 채택)

구성 및 배선 프레임 워크로서 Spring 2가 Mule 2에서 채택되었지만 필요한 XML 구성의 표현력이 부족하기 때문에 대대적 인 점검이되었습니다. 이 문제는 Spring 2에서 XML Schema 기반 구성이 도입되었을 때 해결되었습니다.

Maven으로 빌드

개발 및 배포시 Mule 사용을 단순화 한 가장 큰 개선 사항은 Maven을 사용하는 것입니다. 버전 1.3부터 ​​Maven으로 구성되기 시작했습니다.

MuleSource

2006 년 MuleSource는 "미션 크리티컬 엔터프라이즈 애플리케이션에서 Mule을 사용하여 빠르게 성장하는 커뮤니티를 지원하고 활성화하기 위해"통합되었습니다. 그것은 Mule Project의 핵심 이정표임을 입증했습니다.

Mule ESB의 경쟁자

다음은 Mule ESB의 주요 경쟁 업체입니다.

• WSO2 ESB
• Oracle 서비스 버스
• WebSphere 메시지 브로커
• Aurea CX 플랫폼
• Fiorano ESB
• WebSphere DataPower 게이트웨이
• Workday 비즈니스 프로세스 프레임 워크
• Talend 엔터프라이즈 서비스 버스
• JBoss 엔터프라이즈 서비스 버스
• iWay 서비스 관리자

뮬의 핵심 개념

논의한 바와 같이 Mule ESB는 가볍고 확장 성이 뛰어난 Java 기반 ESB (Enterprise Service Bus) 및 통합 플랫폼입니다. 응용 프로그램에서 사용하는 다양한 기술에 관계없이 Mule ESB를 사용하면 응용 프로그램을 쉽게 통합하여 데이터를 교환 할 수 있습니다. 이 섹션에서는 이러한 통합이 이루어 지도록하는 Mule의 핵심 개념에 대해 논의합니다.

이를 위해서는 아키텍처와 빌딩 블록을 이해해야합니다.

건축물

Mule ESB의 아키텍처는 다음 다이어그램과 같이 전송 계층, 통합 계층 및 응용 프로그램 계층의 세 계층으로 구성됩니다.

일반적으로 Mule 배포를 구성하고 사용자 지정하기 위해 수행 할 수있는 세 가지 유형의 작업이 있습니다.

서비스 구성 요소 개발

이 작업에는 기존 POJO 또는 Spring Bean을 개발하거나 재사용하는 작업이 포함됩니다. POJO는 get 및 set 메서드, 클라우드 커넥터를 생성하는 속성이있는 클래스입니다. 반면 Spring Beans에는 메시지를 풍부하게하는 비즈니스 로직이 포함되어 있습니다.

서비스 오케스트레이션

이 태스크는 기본적으로 메시지 프로세서, 라우터, 변환기 및 필터 구성과 관련된 서비스 중개를 제공합니다.

완성

Mule ESB의 가장 중요한 작업은 사용중인 프로토콜에 관계없이 다양한 응용 프로그램을 통합하는 것입니다. 이를 위해 Mule은 다양한 프로토콜 커넥터에서 메시지를 수신하고 발송할 수있는 전송 방법을 제공합니다. Mule은 기존의 많은 전송 방법을 지원하거나 사용자 지정 전송 방법을 사용할 수도 있습니다.

빌딩 블록

노새 구성에는 다음과 같은 구성 요소가 있습니다.

봄 콩

Spring Bean의 주요 용도는 서비스 컴포넌트를 구성하는 것입니다. 스프링 서비스 컴포넌트를 구축 한 후, 설정 파일이없는 경우 설정 파일을 통해 또는 수동으로 정의 할 수 있습니다.

자치령 대표

기본적으로 Mule Studio 이전에 Anypoint Studio에서 만든 서비스입니다. 에이전트는 서버를 시작하면 생성되고 서버를 중지하면 삭제됩니다.

커넥터

프로토콜에 특정한 매개 변수로 구성된 소프트웨어 구성 요소입니다. 주로 프로토콜 사용을 제어하는 ​​데 사용됩니다. 예를 들어 JMS 커넥터는Connection 그리고이 커넥터는 실제 통신을 담당하는 다양한 주체간에 공유됩니다.

글로벌 구성

이름에서 알 수 있듯이이 빌딩 블록은 전역 속성 및 설정을 지정하는 데 사용됩니다.

글로벌 엔드 포인트

한 흐름에서 여러 번 사용할 수있는 글로벌 요소 탭에서 사용할 수 있습니다.

글로벌 메시지 프로세서

이름에서 알 수 있듯이 메시지 또는 메시지 흐름을 관찰하거나 수정합니다. 변환기 및 필터는 글로벌 메시지 프로세서의 예입니다.

Transformers− 변환기의 주요 작업은 데이터를 한 형식에서 다른 형식으로 변환하는 것입니다. 전역 적으로 정의 할 수 있으며 여러 흐름에서 사용할 수 있습니다.

Filters− 어떤 Mule 메시지를 처리해야하는지 결정하는 필터입니다. 필터는 기본적으로 메시지를 처리하고 서비스로 라우팅하기 위해 충족해야하는 조건을 지정합니다.

모델

에이전트와 달리 스튜디오에서 생성되는 서비스의 논리적 그룹입니다. 특정 모델 내에서 모든 서비스를 시작하고 중지 할 수있는 자유가 있습니다.

Services− 서비스는 비즈니스 로직 또는 구성 요소를 감싸는 서비스입니다. 또한 해당 서비스에 대해 특별히 라우터, 엔드 포인트, 변환기 및 필터를 구성합니다.

Endpoints− 서비스가 메시지를 인바운드 (수신) 및 아웃 바운드 (송신)하는 객체로 정의 할 수 있습니다. 서비스는 끝점을 통해 연결됩니다.

흐름

메시지 프로세서는 흐름을 사용하여 소스와 대상 간의 메시지 흐름을 정의합니다.

뮬 메시지 구조

Mule Message Object 아래에 완전히 래핑 된 Mule 메시지는 Mule 흐름을 통해 애플리케이션을 통과하는 데이터입니다. 구조 Mule의 메시지는 다음 다이어그램에 표시됩니다.

위의 다이어그램에서 볼 수 있듯이 Mule Message는 두 가지 주요 부분으로 구성됩니다.

머리글

다음 두 가지 속성으로 더 표현되는 메시지의 메타 데이터 일뿐입니다.

Inbound Properties− 메시지 소스에 의해 자동으로 설정되는 속성입니다. 사용자가 조작하거나 설정할 수 없습니다. 본질적으로 인바운드 속성은 변경할 수 없습니다.

Outbound Properties− 인바운드 속성과 같은 메타 데이터를 포함하는 속성이며 흐름 과정에서 설정할 수 있습니다. Mule이 자동으로 설정하거나 사용자가 수동으로 설정할 수 있습니다. 본질적으로 아웃 바운드 속성은 변경 가능합니다.

아웃 바운드 속성은 메시지가 한 흐름의 아웃 바운드 끝점에서 전송을 통해 다른 흐름의 인바운드 끝점으로 전달 될 때 인바운드 속성이됩니다.

아웃 바운드 속성은 메시지가 커넥터가 아닌 flow-ref를 통해 새 흐름으로 전달 될 때 아웃 바운드 속성으로 유지됩니다.

유효 탑재량

메시지 객체가 전달하는 실제 비즈니스 메시지를 페이로드라고합니다.

변수

메시지에 대한 사용자 정의 메타 데이터로 정의 할 수 있습니다. 기본적으로 변수는 메시지를 처리하는 응용 프로그램에서 사용하는 메시지에 대한 임시 정보입니다. 메시지와 함께 대상으로 전달되는 것은 아닙니다. 아래에 주어진 세 가지 유형이 있습니다.

Flow variables − 이러한 변수는 해당 변수가 존재하는 흐름에만 적용됩니다.

Session variables − 이러한 변수는 동일한 응용 프로그램 내의 모든 흐름에 적용됩니다.

Record variables − 이러한 변수는 배치의 일부로 처리 된 레코드에만 적용됩니다.

첨부 파일 및 추가 페이로드

이는 메시지 객체에 매번 나타날 필요는없는 메시지 페이로드에 대한 추가 메타 데이터입니다.

이전 장에서 Mule ESB의 기본 사항을 배웠습니다. 이 장에서는이를 설치하고 구성하는 방법에 대해 알아 보겠습니다.

전제 조건

컴퓨터에 Mule을 설치하기 전에 다음 전제 조건을 충족해야합니다.

자바 개발 키트 (JDK)

MULE을 설치하기 전에 시스템에 지원되는 Java 버전이 있는지 확인하십시오. 시스템에 Mule을 성공적으로 설치하려면 JDK 1.8.0을 권장합니다.

운영 체제

다음 운영 체제는 Mule에서 지원됩니다-

• MacOS 10.11.x
• HP-UX 11iV3
• AIX 7.2
• Windows 2016 서버
• Windows 2012 R2 서버
• 윈도우 10
• 윈도우 8.1
• Solaris 11.3
• RHEL 7
• Ubuntu 서버 18.04
• Linux Kernel 3.13 이상

데이터 베이스

Mule Runtime은 독립형 서버로 실행되므로 애플리케이션 서버 또는 데이터베이스가 필요하지 않습니다. 그러나 데이터 저장소에 액세스해야하거나 응용 프로그램 서버를 사용하려면 다음 지원되는 응용 프로그램 서버 또는 데이터베이스를 사용할 수 있습니다.

• Oracle 11g
• Oracle 12c
• MySQL 5.5 이상
• IBM DB2 10
• PostgreSQL 9
• 더비 10
• 마이크로 소프트 SQL 서버 2014

시스템 요구 사항

시스템에 Mule을 설치하기 전에 다음 시스템 요구 사항을 충족해야합니다.

• 가상화 된 환경에서 최소 2GHz CPU 또는 1 개의 가상 CPU
• 최소 1GB RAM
• 최소 4GB 스토리지

Mule 다운로드

Mule 4 바이너리 파일을 다운로드하려면 링크를 클릭하십시오. https://www.mulesoft.com/lp/dl/mule-esb-enterprise 다음과 같이 MuleSoft의 공식 웹 페이지로 연결됩니다.

필요한 세부 정보를 제공하면 Mule 4 바이너리 파일을 Zip 형식으로 얻을 수 있습니다.

Mule 설치 및 실행

이제 Mule 4 바이너리 파일을 다운로드 한 후 압축을 풀고 다음과 같은 환경 변수를 설정합니다. MULE_HOME 추출 된 폴더 내의 Mule 디렉토리에 대해.

예를 들어, Windows 및 Linux / Unix 환경에서 환경 변수는 다음과 같이 Downloads 디렉토리에서 버전 4.1.5로 설정할 수 있습니다.

Windows 환경

$ env:MULE_HOME=C:\Downloads\mule-enterprise-standalone-4.1.5\

Unix / Linux 환경

$ export MULE_HOME=~/Downloads/mule-enterprise-standalone-4.1.5/

이제 Mule이 오류없이 시스템에서 실행 중인지 테스트하려면 다음 명령을 사용하십시오.

Windows 환경

$ $MULE_HOME\bin\mule.bat

Unix / Linux 환경

$ $MULE_HOME/bin/mule

위의 명령은 포 그라운드 모드에서 Mule을 실행합니다. Mule이 실행 중이면 터미널에서 다른 명령을 실행할 수 없습니다. 누르기ctrl-c 터미널에서 명령을 실행하면 Mule이 중지됩니다.

Mule 서비스 시작

Mule을 Windows 서비스 및 Linux / Unix Daemon으로 시작할 수도 있습니다.

Windows 서비스로서의 Mule

Mule을 Windows 서비스로 실행하려면 아래 단계를 따라야합니다.

Step 1 − 먼저 다음 명령을 사용하여 설치합니다 −

$ $MULE_HOME\bin\mule.bat install

Step 2 − 설치가 완료되면 다음 명령을 사용하여 mule을 Windows 서비스로 실행할 수 있습니다.

$ $MULE_HOME\bin\mule.bat start

Linux / Unix 데몬으로서의 Mule

Mule을 Linux / Unix Daemon으로 실행하려면 다음 단계를 따라야합니다.

Step 1 − 다음 명령을 사용하여 설치 −

$ $MULE_HOME/bin/mule install

Step 2 − 설치가 완료되면 다음 명령을 사용하여 mule을 Windows 서비스로 실행할 수 있습니다. −

$ $MULE_HOME/bin/mule start

Example

다음 예제는 Mule을 Unix Daemon으로 시작합니다.

$ $MULE_HOME/bin/mule start
MULE_HOME is set to ~/Downloads/mule-enterprise-standalone-4.1.5
MULE_BASE is set to ~/Downloads/mule-enterprise-standalone-4.1.5
Starting Mule Enterprise Edition...
Waiting for Mule Enterprise Edition.................
running: PID:87329

Mule 앱 배포

다음 단계를 통해 Mule 앱을 배포 할 수 있습니다.

Step 1 − 먼저 Mule을 시작합니다.

Step 2 − Mule이 시작되면 JAR 패키지 파일을 다음 위치로 이동하여 Mule 애플리케이션을 배포 할 수 있습니다. apps 디렉토리 $MULE_HOME.

Mule 서비스 중지

우리는 사용할 수 있습니다 stopMule을 중지하는 명령. 예를 들어, 다음 예제는 Mule을 Unix Daemon으로 시작합니다.

$ $MULE_HOME/bin/mule stop
MULE_HOME is set to /Applications/mule-enterprise-standalone-4.1.5
MULE_BASE is set to /Applications/mule-enterprise-standalone-4.1.5
Stopping Mule Enterprise Edition...
Stopped Mule Enterprise Edition.

우리는 또한 사용할 수 있습니다 remove시스템에서 Mule 서비스 또는 데몬을 제거하는 명령. 다음 예제는 Mule을 Unix Daemon으로 제거합니다.

$ $MULE_HOME/bin/mule remove
MULE_HOME is set to /Applications/mule-enterprise-standalone-4.1.5
MULE_BASE is set to /Applications/mule-enterprise-standalone-4.1.5
Detected Mac OSX:
Mule Enterprise Edition is not running.
Removing Mule Enterprise Edition daemon...

MuleSoft의 Anypoint Studio는 사용자 친화적입니다. IDE (integration development environment)Mule 애플리케이션 설계 및 테스트에 사용됩니다. Eclipse 기반 IDE입니다. Mule Palette에서 커넥터를 쉽게 끌어 올 수 있습니다. 즉, Anypoint Studio는 흐름 개발 등을위한 Eclipse 기반 IDE입니다.

전제 조건

모든 OS (예 : Windows, Mac 및 Linux / Unix)에 Mule을 설치하기 전에 다음 전제 조건을 충족해야합니다.

Java Development Kit (JDK)− Mule을 설치하기 전에 시스템에 지원되는 Java 버전이 있는지 확인하십시오. 시스템에 Anypoint를 성공적으로 설치하려면 JDK 1.8.0을 권장합니다.

Anypoint Studio 다운로드 및 설치

다른 운영 체제에서 Anypoint Studio를 다운로드하고 설치하는 절차는 다를 수 있습니다. 다음으로 다양한 운영 체제에서 Anypoint Studio를 다운로드하고 설치하기 위해 따라야 할 단계가 있습니다.

Windows에서

Windows에서 Anypoint Studio를 다운로드하고 설치하려면 아래 단계를 따라야합니다.

Step 1 − 먼저 링크를 클릭하십시오. https://www.mulesoft.com/lp/dl/studio 스튜디오를 다운로드하려면 하향식 목록에서 Windows 운영 체제를 선택하십시오.

Step 2 − 이제 ‘C:\’ 루트 폴더.

Step 3 − 추출 된 Anypoint Studio를 엽니 다.

Step 4− 기본 작업 공간을 수락하려면 확인을 클릭합니다. 처음로드 될 때 환영 메시지를 받게됩니다.

Step 5 − 이제 시작하기 버튼을 클릭하여 Anypoint Studio를 사용하십시오.

OS X에서

OS X에 Anypoint Studio를 다운로드하여 설치하려면 아래 단계를 따라야합니다.

Step 1 − 먼저 링크를 클릭하십시오. https://www.mulesoft.com/lp/dl/studio 스튜디오를 다운로드합니다.

Step 2− 이제 추출하십시오. OS 버전 Sierra를 사용하는 경우 추출 된 앱을/Applications folder 시작하기 전에.

Step 3 − 추출 된 Anypoint Studio를 엽니 다.

Step 4− 기본 작업 공간을 수락하려면 확인을 클릭합니다. 처음로드 될 때 환영 메시지를 받게됩니다.

Step 5 − 이제 Get Started 버튼을 눌러 Anypoint Studio를 사용하세요.

작업 공간에 대한 사용자 지정 경로를 사용하려는 경우 Anypoint Studio는 Linux / Unix 시스템에서 사용되는 ~ 물결표를 확장하지 않습니다. 따라서 작업 공간을 정의 할 때 절대 경로를 사용하는 것이 좋습니다.

Linux에서

Linux에서 Anypoint Studio를 다운로드하여 설치하려면 아래 단계를 따라야합니다.

Step 1 − 먼저 링크를 클릭하십시오. https://www.mulesoft.com/lp/dl/studio 하향식 목록에서 Linux 운영 체제를 선택하여 스튜디오를 다운로드하십시오.

Step 2 − 이제 추출하십시오.

Step 3 − 다음으로 추출 된 Anypoint Studio를 엽니 다.

Step 4− 기본 작업 공간을 수락하려면 확인을 클릭합니다. 처음로드 될 때 환영 메시지를 받게됩니다.

Step 5 − 이제 시작하기 버튼을 클릭하여 Anypoint Studio를 사용하십시오.

작업 공간에 대한 사용자 지정 경로를 사용하려는 경우 Anypoint Studio는 Linux / Unix 시스템에서 사용되는 ~ 물결표를 확장하지 않습니다. 따라서 작업 공간을 정의 할 때 절대 경로를 사용하는 것이 좋습니다.

Linux에서 완전한 Studio 테마를 사용하려면 GTK 버전 2를 설치하는 것이 좋습니다.

Anypoint Studio의 특징

다음은 Mule 응용 프로그램을 구축하는 동안 생산성을 향상시키는 Anypoint studio의 몇 가지 기능입니다.

• 로컬 런타임 내에서 Mule 애플리케이션을 즉시 실행할 수 있습니다.

• Anypoint Studio는 API 정의 파일 및 Mule 도메인 구성을위한 시각적 편집기를 제공합니다.

• 생산성을 향상시키는 단위 테스트 프레임 워크가 내장되어 있습니다.

• Anypoint Studio는 CloudHub에 배포하기위한 기본 제공 지원을 제공합니다.

• 다른 Anypoint Platform 조직에서 템플릿, 예제, 정의 및 기타 리소스를 가져 오기 위해 Exchange와 통합 할 수있는 기능이 있습니다.

Anypoint Studio 편집기는 애플리케이션, API, 속성 및 구성 파일을 디자인하는 데 도움이됩니다. 디자인과 함께 편집하는데도 도움이됩니다. 이를 위해 Mule 구성 파일 편집기가 있습니다. 이 편집기를 열려면 다음에서 응용 프로그램 XML 파일을 두 번 클릭하십시오./src/main/mule.

응용 프로그램을 사용하기 위해 Mule 구성 파일 편집기 아래에 다음 세 개의 탭이 있습니다.

메시지 흐름 탭

이 탭은 작업 흐름을 시각적으로 보여줍니다. 기본적으로 흐름을 시각적으로 확인하는 데 도움이되는 캔버스가 포함되어 있습니다. Mule Palette에서 캔버스에 이벤트 프로세서를 추가하려면 끌어서 놓기 만하면 캔버스에 반영됩니다.

이벤트 프로세서를 클릭하면 선택한 프로세서에 대한 속성이있는 Mule 속성보기를 볼 수 있습니다. 편집 할 수도 있습니다.

글로벌 요소 탭

이 탭에는 모듈에 대한 전역 Mule 구성 요소가 포함되어 있습니다. 이 탭에서 구성 파일을 생성, 편집 또는 삭제할 수 있습니다.

구성 XML 탭

이름에서 알 수 있듯이 Mule 애플리케이션을 정의하는 XML이 포함되어 있습니다. 여기서 수행하는 모든 변경 사항은 메시지 플로우 탭 아래의 이벤트 프로세서 특성보기와 캔버스에 반영됩니다.

견해

활성 편집기의 경우 Anypoint 스튜디오는 뷰의 도움으로 프로젝트 메타 데이터, 속성의 그래픽 표현을 제공합니다. 사용자는 Mule 프로젝트에서보기를 이동, 닫기 및 추가 할 수 있습니다. 다음은 Anypoint 스튜디오의 기본보기입니다.

패키지 탐색기

패키지 탐색기보기의 주요 작업은 Mule 프로젝트로 구성된 프로젝트 폴더 및 파일을 표시하는 것입니다. Mule 프로젝트 폴더 옆에있는 화살표를 클릭하여 확장하거나 축소 할 수 있습니다. 폴더 또는 파일을 두 번 클릭하여 열 수 있습니다. 스크린 샷을보세요-

뮬 팔레트

Mule Palette보기는 모듈 및 관련 작업과 함께 범위, 필터 및 흐름 제어 라우터와 같은 이벤트 프로세서를 보여줍니다. Mule Palette보기의 주요 작업은 다음과 같습니다.

• 이보기는 프로젝트에서 모듈과 커넥터를 관리하는 데 도움이됩니다.
• Exchange에서 새 요소를 추가 할 수도 있습니다.

스크린 샷을보세요-

노새 속성

이름에서 알 수 있듯이 캔버스에서 현재 선택된 모듈의 속성을 편집 할 수 있습니다. 노새 속성보기에는 다음이 포함됩니다.

• 페이로드의 데이터 구조에 대한 실시간 정보를 제공하는 DataSense Explorer.

• 인바운드 및 아웃 바운드 속성 (사용 가능한 경우) 또는 변수.

아래는 스크린 샷입니다-

콘솔

Mule 애플리케이션을 생성하거나 실행할 때마다 임베디드 Mule 서버는 Studio에서보고 한 이벤트 및 문제 (있는 경우) 목록을 표시합니다. 콘솔보기에는 해당 임베디드 Mule 서버의 콘솔이 포함되어 있습니다. 스크린 샷을보세요-

문제보기

뮬 프로젝트를 작업하는 동안 많은 문제가 발생할 수 있습니다. 이러한 모든 문제는 문제보기에 표시됩니다. 아래는 스크린 샷입니다

관점

Anypoint Studio에서는 지정된 배열의보기 및 편집기 모음입니다. Anypoint Studio에는 두 가지 관점이 있습니다.

Mule Design Perspective − Studio에서 얻는 기본 관점입니다.

Mule Debug Perspective − Anypoint Studio에서 제공하는 또 다른 관점은 Mule Debug Perspective입니다.

다른 한편으로, 우리는 또한 우리 자신의 관점을 만들 수 있고 기본보기를 추가하거나 제거 할 수 있습니다.

이 장에서는 MuleSoft의 Anypoint Studio에서 첫 번째 Mule 애플리케이션을 만들 것입니다. 생성하려면 먼저 Anypoint Studio를 시작해야합니다.

Anypoint Studio 시작

Anypoint Studio를 클릭하여 실행하십시오. 처음 실행하는 경우 다음 창이 표시됩니다.

Anypoint Studio의 사용자 인터페이스

Go to Workspace 버튼을 클릭하면 다음과 같은 Anypoint Studio의 사용자 인터페이스로 이동합니다.

Mule 애플리케이션 생성 단계

Mule 애플리케이션을 생성하려면 다음 단계를 따르십시오.

새 프로젝트 생성

Mule 응용 프로그램을 만드는 첫 번째 단계는 새 프로젝트를 만드는 것입니다. 경로를 따라 할 수 있습니다.FILE → NEW → Mule Project 아래와 같이-

프로젝트 이름 지정

위에서 설명한대로 새 Mule Project를 클릭하면 프로젝트 이름 및 기타 사양을 묻는 새 창이 열립니다. 프로젝트 이름, 'TestAPP1'를 클릭 한 다음 마침 버튼을 클릭합니다.

Finish 버튼을 클릭하면 MuleProject 용으로 구축 된 작업 공간이 열립니다. ‘TestAPP1’. 당신은 모든 것을 볼 수 있습니다Editors 과 Views 이전 장에서 설명했습니다.

커넥터 구성

여기서는 HTTP Listener를위한 간단한 Mule 애플리케이션을 빌드 할 것입니다. 이를 위해 Mule Palette에서 HTTP Listener 커넥터를 끌어서 아래와 같이 작업 공간에 놓아야합니다.

이제 구성해야합니다. 위와 같이 기본 설정에서 커넥터 구성 후 녹색 + 기호를 클릭하십시오.

확인을 클릭하면 HTTP Listener 속성 페이지로 돌아갑니다. 이제 일반 탭 아래에 경로를 제공해야합니다. 이 특정 예에서 우리는/FirstAPP 경로 이름으로.

Set Payload Connector 구성

이제 Set Payload 커넥터를 가져와야합니다. 또한 다음과 같이 설정 탭에서 값을 제공해야합니다.

This is my first Mule Application은이 예에서 제공된 이름입니다.

Mule 애플리케이션 실행

이제 저장하고 Run as Mule Application 아래와 같이-

다음과 같이 응용 프로그램을 배포하는 콘솔에서 확인할 수 있습니다.

첫 번째 Mule 애플리케이션을 성공적으로 구축했음을 보여줍니다.

Mule 응용 프로그램 확인

이제 앱이 실행 중인지 여부를 테스트해야합니다. Go to POSTMAN, Chrome 앱을 열고 URL을 입력하십시오. http:/localhost:8081. 다음과 같이 Mule 애플리케이션을 빌드하는 동안 제공 한 메시지를 보여줍니다.

DataWeave는 기본적으로 MuleSoft 표현 언어입니다. 주로 Mule 애플리케이션을 통해 수신 된 데이터에 액세스하고 변환하는 데 사용됩니다. Mule 런타임은 Mule 애플리케이션에서 스크립트와 표현식을 실행하는 역할을하며 DataWeave는 Mule 런타임과 강력하게 통합됩니다.

DataWeave 언어의 특징

다음은 DataWeave 언어의 몇 가지 중요한 기능입니다.

데이터는 한 형식에서 다른 형식으로 매우 쉽게 변환 할 수 있습니다. 예를 들어 application / json을 application / xml로 변환 할 수 있습니다. 입력 페이로드는 다음과 같습니다.

{
   "title": "MuleSoft",
   "author": " tutorialspoint.com ",
   "year": 2019
}

다음은 DataWeave의 변환 코드입니다.

%dw 2.0
output application/xml
---
{
   order: {
      'type': 'Tutorial', 
      'title': payload.title, 
      'author': upper(payload.author), 
      'year': payload.year
   }
}

다음으로 output 페이로드는 다음과 같습니다-

<?xml version = '1.0' encoding = 'UTF-8'?>
<order>
   <type>Tutorial</type>
   <title>MuleSoft</title>
   <author>tutorialspoint.com</author>
   <year>2019</year>
</order>

변환 구성 요소는 단순 데이터 변환과 복잡한 데이터 변환을 모두 수행하는 스크립트를 만드는 데 사용할 수 있습니다.

대부분의 Mule 메시지 프로세서가 DataWeave 표현식을 지원하므로 필요한 Mule 이벤트의 일부에서 핵심 DataWeave 함수에 액세스하고 사용할 수 있습니다.

전제 조건

컴퓨터에서 DataWeave 스크립트를 사용하기 전에 다음 전제 조건을 충족해야합니다.

• Dataweave 스크립트를 사용하려면 Anypoint Studio 7이 필요합니다.

• Anypoint Studio를 설치 한 후 DataWeave 스크립트를 사용하려면 Transform Message 컴포넌트로 프로젝트를 설정해야합니다.

예제와 함께 DataWeave 스크립트를 사용하는 단계

DataWeave 스크립을 사용하려면 아래 단계를 따라야합니다.

Step 1

먼저, 이전 장에서했던 것처럼 새 프로젝트를 설정해야합니다. File → New → Mule Project.

Step 2

다음으로 프로젝트의 이름을 제공해야합니다. 이 예에서는 이름을 지정합니다.Mule_test_script.

Step 3

이제 우리는 Transform Message component ...에서 Mule Palette tab 으로 canvas. 다음과 같이 표시됩니다-

Step 4

다음으로 Transform Message component탭에서 미리보기를 클릭하여 미리보기 창을 엽니 다. 미리보기 옆에있는 빈 사각형을 클릭하여 소스 코드 영역을 확장 할 수 있습니다.

Step 5

이제 DataWeave 언어로 스크립팅을 시작할 수 있습니다.

예

다음은 두 문자열을 하나로 연결하는 간단한 예입니다.

위의 DataWeave 스크립트에는 키-값 쌍이 있습니다. ({ myString: ("hello" ++ "World") }) 두 문자열을 하나로 연결합니다.

스크립팅 모듈은 사용자가 Mule에서 스크립팅 언어를 사용할 수 있도록합니다. 간단히 말해서 스크립팅 모듈은 스크립팅 언어로 작성된 사용자 지정 논리를 교환 할 수 있습니다. 스크립트는 구현 또는 변환기로 사용할 수 있습니다. 식 평가, 즉 메시지 라우팅 제어에 사용할 수 있습니다.

Mule에는 다음과 같은 지원되는 스크립팅 언어가 있습니다.

• Groovy
• Python
• JavaScript
• Ruby

스크립팅 모듈을 설치하는 방법?

실제로 Anypoint Studio에는 스크립팅 모듈이 함께 제공됩니다. Mule Palette에서 모듈을 찾을 수없는 경우 다음을 사용하여 추가 할 수 있습니다.+Add Module. 추가 한 후 Mule 애플리케이션에서 스크립팅 모듈 작업을 사용할 수 있습니다.

구현 예

논의한 바와 같이, 우리는 작업 공간을 생성하기 위해 모듈을 캔버스에 끌어다 놓아야하고 우리의 애플리케이션에서 사용해야합니다. 다음은 그것의 예입니다-

우리는 이미 HTTP Listener 구성 요소를 구성하는 방법을 알고 있습니다. 따라서 스크립팅 모듈 구성에 대해 논의 할 것입니다. 스크립팅 모듈을 구성하려면 아래 단계를 따라야합니다.

Step 1

Mule Palette에서 스크립팅 모듈을 검색하고 EXECUTE 위와 같이 스크립팅 모듈을 흐름에 적용합니다.

Step 2

이제 동일한 항목을 두 번 클릭하여 구성 실행 탭을 엽니 다.

Step 3

아래의 General 탭에서 코드를 제공해야합니다. Code text window 아래와 같이-

Step 4

마지막으로 우리는 Engine실행 구성 요소에서. 엔진 목록은 다음과 같습니다.

• Groovy
• Nashorn(javaScript)
• jython(Python)
• jRuby(Ruby)

구성 XML 편집기에서 위 실행 예제의 XML은 다음과 같습니다.

<scripting:execute engine="jython" doc:name = "Script">
   <scripting:code>
      def factorial(n):
         if n == 0: return 1
      return n * factorial(n-1)
      result = factorial(10)
   </scripting:code>
</scripting:execute>

메시지 소스

Mule 4에는 Mule 3 메시지보다 단순화 된 모델이있어 정보를 덮어 쓰지 않고도 커넥터에서 일관된 방식으로 데이터 작업을 더 쉽게 수행 할 수 있습니다. Mule 4 메시지 모델에서 각 Mule 이벤트는 다음 두 가지로 구성됩니다.a message and variables associated with it.

Mule 메시지에는 페이로드와 해당 속성이 있으며, 속성은 주로 파일 크기와 같은 메타 데이터입니다.

그리고 변수는 연산 결과, 보조 값 등과 같은 임의의 사용자 정보를 보유합니다.

인바운드

Mule 3의 인바운드 속성은 이제 Mule 4의 속성이됩니다. 인바운드 속성은 메시지 소스를 통해 얻은 페이로드에 대한 추가 정보를 저장하지만 이제 Mule 4에서는 속성의 도움으로 수행됩니다. 속성에는 다음과 같은 장점이 있습니다.

• 속성의 도움으로 사용 가능한 데이터를 쉽게 볼 수 있습니다. 속성은 강력한 유형이기 때문입니다.

• 속성에 포함 된 정보에 쉽게 액세스 할 수 있습니다.

다음은 Mule 4의 일반적인 메시지 예입니다.

배 밖으로

추가 데이터를 보내려면 Mule 3의 아웃 바운드 속성을 Mule 커넥터 및 전송에서 명시 적으로 지정해야합니다. 그러나 Mule 4에서는 각각에 대해 DataWeave 표현식을 사용하여 각각을 개별적으로 설정할 수 있습니다. 주요 흐름에서 부작용을 일으키지 않습니다.

예를 들어, 아래의 DataWeave 표현식은 HTTP 요청을 수행하고 메시지 속성을 설정할 필요없이 헤더와 쿼리 매개 변수를 생성합니다. 이것은 아래 코드에 나와 있습니다.

<http:request path = "M_issue" config-ref="http" method = "GET">
   <http:headers>#[{'path':'input/issues-list.json'}]</http:headers>
   <http:query-params>#[{'provider':'memory-provider'}]</http:query-params>
</http:request>

메시지 프로세서

Mule이 메시지 소스에서 메시지를 수신하면 메시지 프로세서 작업이 시작됩니다. Mule은 하나 이상의 메시지 프로세서를 사용하여 흐름을 통해 메시지를 처리합니다. 메시지 프로세서의 주요 작업은 메시지가 Mule 흐름을 통과 할 때 메시지를 변환, 필터링, 강화 및 처리하는 것입니다.

뮬 프로세서의 분류

다음은 기능을 기반으로 한 뮬 프로세서의 범주입니다.

• Connectors− 이러한 메시지 프로세서는 데이터를 송수신합니다. 또한 표준 프로토콜 또는 타사 API를 통해 데이터를 외부 데이터 소스에 연결합니다.

• Components − 이러한 메시지 프로세서는 본질적으로 유연하며 Java, JavaScript, Groovy, Python 또는 Ruby와 같은 다양한 언어로 구현 된 비즈니스 로직을 수행합니다.

• Filters − 메시지를 필터링하고 특정 기준에 따라 특정 메시지 만 흐름에서 계속 처리되도록 허용합니다.

• Routers −이 메시지 프로세서는 라우팅, 재 배열 또는 분할 할 메시지의 흐름을 제어하는 ​​데 사용됩니다.

• Scopes − 기본적으로 흐름 내에서 세분화 된 동작을 정의 할 목적으로 코드 스 니펫을 래핑합니다.

• Transformers − 변환기의 역할은 시스템 간의 통신을 용이하게하기 위해 메시지 페이로드 유형과 데이터 형식을 변환하는 것입니다.

• Business Events − 기본적으로 핵심 성과 지표와 관련된 데이터를 캡처합니다.

• Exception strategies − 이러한 메시지 프로세서는 메시지 처리 중에 발생하는 모든 유형의 오류를 처리합니다.

Mule의 가장 중요한 기능 중 하나는 구성 요소와 함께 라우팅, 변환 및 처리를 수행 할 수 있다는 것입니다. 이로 인해 다양한 요소를 결합한 Mule 애플리케이션의 구성 파일의 크기가 매우 큽니다.

다음은 Mule에서 제공하는 구성 패턴의 유형입니다-

• 간단한 서비스 패턴
• Bridge
• Validator
• HTTP 프록시
• WS 프록시

구성 요소 구성

Anypoint studio에서는 아래 단계에 따라 구성 요소를 구성 할 수 있습니다.

Step 1

Mule 애플리케이션에서 사용할 컴포넌트를 드래그해야합니다. 예를 들어, 여기서는 다음과 같이 HTTP 리스너 컴포넌트를 사용합니다.

Step 2

다음으로 구성 요소를 두 번 클릭하여 구성 창을 가져옵니다. HTTP 리스너의 경우 다음과 같습니다.

Step 3

프로젝트의 요구 사항에 따라 구성 요소를 구성 할 수 있습니다. 예를 들어, 우리가 HTTP 리스너 구성 요소에 대해 수행했다고 가정 해 보겠습니다.

핵심 구성 요소는 Mule 앱에서 작업 흐름의 중요한 구성 요소 중 하나입니다. Mule 이벤트 처리를위한 로직은 이러한 핵심 구성 요소에서 제공합니다. Anypoint studio에서 이러한 핵심 구성 요소에 액세스하려면 아래와 같이 Mule Palette에서 Core를 클릭하면됩니다.

다음은 다양합니다 core components and their working in Mule 4 −

맞춤형 비즈니스 이벤트

이 핵심 구성 요소는 Mule 앱에서 비즈니스 트랜잭션을 처리하는 메시지 프로세서뿐만 아니라 흐름에 대한 정보 수집에 사용됩니다. 즉, 사용자 정의 비즈니스 이벤트 구성 요소를 사용하여 작업 흐름에 다음을 추가 할 수 있습니다.

• Metadata
• 핵심 성과 지표 (KPI)

KPI를 추가하는 방법은 무엇입니까?

다음은 Mule 앱의 흐름에 KPI를 추가하는 단계입니다.

Step 1 − 뮬 팔로우 Palette → Core → Components → Custom Business Event, Mule 앱의 작업 흐름에 사용자 지정 비즈니스 이벤트 구성 요소를 추가합니다.

Step 2 − 구성 요소를 클릭하여 엽니 다.

Step 3 − 이제 표시 이름 및 이벤트 이름에 대한 값을 제공해야합니다.

Step 4 − 메시지 페이로드에서 정보를 캡처하려면 다음과 같이 KPI를 추가합니다.

• KPI의 이름 (키) ( 추적 : 메타 데이터 요소) 및 값을 제공하십시오. 이름은 Runtime Manager의 검색 인터페이스에서 사용됩니다.

• Mule 표현식이 될 수있는 값을 지정하십시오.

예

다음 표는 이름과 값이있는 KPI 목록으로 구성되어 있습니다.

이름	표현 / 가치
학생 명부	# [페이로드 [ 'RollNo']]
학생 이름	# [페이로드 [ '이름']]

동적 평가

이 핵심 구성 요소는 Mule 앱에서 스크립트를 동적으로 선택하는 데 사용됩니다. Transform Message Component를 통해 하드 코어 스크립트를 사용할 수도 있지만 Dynamic Evaluate 구성 요소를 사용하는 것이 더 좋은 방법입니다. 이 핵심 구성 요소는 다음과 같이 작동합니다.

• 첫째, 다른 스크립트를 생성해야하는 표현식을 평가합니다.
• 그런 다음 최종 결과를 위해 해당 스크립트를 평가합니다.

이런 식으로 스크립트를 하드 코딩하는 대신 동적으로 선택할 수 있습니다.

예

다음은 Id 쿼리 매개 변수를 통해 데이터베이스에서 스크립트를 선택하고 MyScript 라는 변수에 해당 스크립트를 저장하는 예입니다 . 이제 동적 평가 구성 요소는 변수에 액세스하여 스크립트를 호출하여 다음에서 이름 변수를 추가 할 수 있습니다.UName 검색어 매개 변수.

흐름의 XML 구성은 다음과 같습니다.

<flow name = "DynamicE-example-flow">
   <http:listener config-ref = "HTTP_Listener_Configuration" path = "/"/>
   <db:select config-ref = "dbConfig" target = "myScript">
      <db:sql>#["SELECT script FROM SCRIPTS WHERE ID = 
         $(attributes.queryParams.Id)"]
      </db:sql>
   </db:select>
   <ee:dynamic-evaluate expression = "#[vars.myScript]">
      <ee:parameters>#[{name: attributes.queryParams.UName}]</ee:parameters>
   </ee:dynamic-evaluate>
</flow>

스크립트는 메시지, 페이로드, 변수 또는 속성과 같은 컨텍스트 변수를 사용할 수 있습니다. 그러나 사용자 정의 컨텍스트 변수를 추가하려면 키-값 쌍 세트를 제공해야합니다.

동적 평가 구성

다음 표는 동적 평가 구성 요소를 구성하는 방법을 제공합니다-

들	값	기술	예
표현	DataWeave 표현식	최종 스크립트로 평가할 표현식을 지정합니다.	expression = "# [vars.generateOrderScript]"
매개 변수	DataWeave 표현식	키-값 쌍을 지정합니다.	# [{joiner : 'and', id : payload.user.id}]

흐름 참조 구성 요소

Mule 이벤트를 다른 흐름 또는 하위 흐름으로 라우팅하고 동일한 Mule 앱 내에서 되돌리려면 흐름 참조 구성 요소가 올바른 옵션입니다.

형질

다음은이 핵심 구성 요소의 특성입니다.

• 이 핵심 구성 요소를 사용하면 참조 된 전체 흐름을 현재 흐름의 단일 구성 요소처럼 처리 할 수 ​​있습니다.

• Mule 애플리케이션을 별개의 재사용 가능한 단위로 나눕니다. 예를 들어 흐름은 정기적으로 파일을 나열합니다. 목록 작업의 출력을 처리하는 다른 흐름을 참조 할 수 있습니다.

• 이러한 방식으로 전체 처리 단계를 추가하는 대신 처리 흐름을 가리키는 흐름 참조를 추가 할 수 있습니다. 아래 스크린 샷은 흐름 참조 핵심 구성 요소가 이름이 지정된 하위 흐름을 가리키고 있음을 보여줍니다.ProcessFiles.

일

Flow Ref 구성 요소의 작동은 다음 다이어그램의 도움으로 이해할 수 있습니다.

다이어그램은 한 흐름이 동일한 애플리케이션의 다른 흐름을 참조 할 때 Mule 애플리케이션의 처리 순서를 보여줍니다. Mule 응용 프로그램의 기본 작업 흐름이 트리거되면 Mule 이벤트가 전체를 이동하고 Mule 이벤트가 Flow Reference에 도달 할 때까지 흐름을 실행합니다.

Flow Reference에 도달 한 후 Mule 이벤트는 참조 된 흐름을 처음부터 끝까지 실행합니다. Mule 이벤트가 Ref Flow 실행을 마치면 메인 플로우로 돌아갑니다.

예

더 나은 이해를 위해 let us use this component in Anypoint Studio. 이 예에서는 이전 장에서했던 것처럼 HTTP 리스너를 사용하여 메시지를 GET합니다. 따라서 구성 요소를 드래그 앤 드롭하고 구성 할 수 있습니다. 그러나이 예에서는 아래에 표시된 것처럼 Sub-flow 구성 요소를 추가하고 그 아래에 Payload 구성 요소를 설정해야합니다.

다음으로 구성해야합니다. Set Payload, 더블 클릭하면됩니다. 여기서는 아래와 같이“Sub flow execution”이라는 값을 제공합니다.

하위 흐름 구성 요소를 성공적으로 구성한 후에는 메인 흐름의 Set Payload 후에 설정할 Flow Reference 구성 요소가 필요합니다. 아래 그림과 같이 Mule Palette에서 드래그 앤 드롭 할 수 있습니다.

다음으로 흐름 참조 구성 요소를 구성하는 동안 아래와 같이 일반 탭에서 흐름 이름을 선택해야합니다.

이제이 애플리케이션을 저장하고 실행합니다. 이를 테스트하려면 POSTMAN으로 이동하여http:/localhost:8181/FirstAPP URL 표시 줄에 하위 흐름이 실행되었다는 메시지가 표시됩니다.

로거 구성 요소

logger라는 핵심 구성 요소는 오류 메시지, 상태 알림, 페이로드 등과 같은 중요한 정보를 로깅하여 Mule 애플리케이션을 모니터링하고 디버그하는 데 도움이됩니다. AnyPoint 스튜디오에서는 Console.

장점

다음은 Logger Component의 몇 가지 장점입니다-

• 이 핵심 구성 요소를 작업 흐름의 어느 곳에 나 추가 할 수 있습니다.
• 우리가 지정한 문자열을 기록하도록 구성 할 수 있습니다.
• 우리가 작성한 DataWeave 표현식의 출력으로 구성 할 수 있습니다.
• 문자열과 표현식의 조합으로 구성 할 수도 있습니다.

예

아래 예제는 브라우저의 Set Payload에 "Hello World"메시지를 표시하고 메시지도 로깅합니다.

다음은 위의 예에서 흐름의 XML 구성입니다.

<http:listener-config name = "HTTP_Listener_Configuration" host = "localhost" port = "8081"/>
<flow name = "mymuleprojectFlow">
   <http:listener config-ref="HTTP_Listener_Configuration" path="/"/>
   <set-payload value="Hello World"/>
   <logger message = "#[payload]" level = "INFO"/>
</flow>

전송 메시지 구성 요소

전송 구성 요소라고도하는 변환 메시지 구성 요소를 사용하면 입력 데이터를 새 출력 형식으로 변환 할 수 있습니다.

혁신을 구축하는 방법

우리는 다음 두 가지 방법을 사용하여 변화를 구축 할 수 있습니다.

Drag-and-Drop Editor (Graphical View)− 이것은 우리의 변혁을 구축하기 위해 처음이자 가장 많이 사용되는 방법입니다. 이 방법에서는이 구성 요소의 시각적 매퍼를 사용하여 들어오는 데이터 구조의 요소를 끌어서 놓을 수 있습니다. 예를 들어, 다음 다이어그램에서 두 개의 트리보기는 입력 및 출력의 예상 메타 데이터 구조를 보여줍니다. 입력을 출력 필드에 연결하는 선은 두 트리보기 간의 매핑을 나타냅니다.

Script View− 변환의 시각적 매핑은 Mule 코드 용 언어 인 DataWeave를 사용하여 표현할 수도 있습니다. 집계, 정규화, 그룹화, 조인, 파티셔닝, 피벗 및 필터링과 같은 일부 고급 변환에 대한 코딩을 수행 할 수 있습니다. 예는 다음과 같습니다.

이 핵심 구성 요소는 기본적으로 변수, 속성 또는 메시지 페이로드에 대한 입력 및 출력 메타 데이터를 허용합니다. 다음에 대한 형식 별 리소스를 제공 할 수 있습니다.

• CSV
• Schema
• 플랫 파일 스키마
• JSON
• 개체 클래스
• 간단한 유형
• XML 스키마
• Excel 열 이름 및 유형
• 고정 너비 열 이름 및 유형

엔드 포인트에는 기본적으로 Mule 애플리케이션의 작업 흐름에서 처리를 트리거하거나 시작하는 구성 요소가 포함됩니다. 그들 불리는Source Anypoint Studio에서 Triggers뮬의 디자인 센터에서. Mule 4의 중요한 끝점 중 하나는Scheduler component.

스케줄러 끝점

이 구성 요소는 시간 기반 조건에서 작동합니다. 즉, 시간 기반 조건이 충족 될 때마다 흐름을 트리거 할 수 있습니다. 예를 들어 스케줄러는 이벤트를 트리거하여 10 초마다 Mule 작업 흐름을 시작할 수 있습니다. 유연한 Cron 표현식을 사용하여 스케줄러 엔드 포인트를 트리거 할 수도 있습니다.

스케줄러에 대한 중요 사항

Scheduler 이벤트를 사용하는 동안 다음과 같이 몇 가지 중요한 사항을 처리해야합니다.

• 스케줄러 엔드 포인트는 Mule 런타임이 실행되는 시스템의 시간대를 따릅니다.

• Mule 애플리케이션이 CloudHub에서 실행중인 경우 스케줄러는 CloudHub 작업자가 실행중인 지역의 시간대를 따릅니다.

• 주어진 시간에 스케줄러 엔드 포인트에 의해 트리거 된 하나의 흐름 만 활성화 될 수 있습니다.

• Mule 런타임 클러스터에서 스케줄러 엔드 포인트는 기본 노드에서만 실행되거나 트리거됩니다.

스케줄러를 구성하는 방법

위에서 설명한 것처럼 일정 간격으로 트리거되도록 스케줄러 엔드 포인트를 구성하거나 Cron 표현식을 제공 할 수도 있습니다.

스케줄러를 구성하는 매개 변수 (고정 간격 용)

다음은 일정 간격으로 흐름을 트리거하도록 스케줄러를 설정하는 매개 변수입니다.

Frequency− 기본적으로 스케줄러 엔드 포인트가 Mule 흐름을 트리거하는 빈도를 설명합니다. 이를위한 시간 단위는 시간 단위 필드에서 선택할 수 있습니다. 이에 대한 값을 제공하지 않으면 기본값 인 1000이 사용됩니다. 반면에 0 또는 음수 값을 제공하면 기본값도 사용됩니다.

Start Delay− 응용 프로그램이 시작된 후 처음으로 Mule 흐름을 트리거하기 전에 기다려야하는 시간입니다. 시작 지연 값은 주파수와 동일한 시간 단위로 표현됩니다. 기본값은 0입니다.

Time Unit− 주파수 및 시작 지연 시간 단위를 설명합니다. 시간 단위의 가능한 값은 Milliseconds, Seconds, Minute, Hours, Days입니다. 기본값은 밀리 초입니다.

스케줄러를 구성하기위한 매개 변수 (Cron 표현식의 경우)

실제로 Cron은 시간 및 날짜 정보를 설명하는 데 사용되는 표준입니다. 유연한 Cron 표현식을 사용하여 스케줄러를 트리거하는 경우 스케줄러 엔드 포인트는 매초마다 추적하고 Quartz Cron 표현식이 시간-날짜 설정과 일치 할 때마다 Mule 이벤트를 생성합니다. Cron 표현식을 사용하면 이벤트를 한 번만 또는 일정한 간격으로 트리거 할 수 있습니다.

다음 표는 여섯 가지 필수 설정의 날짜-시간 표현을 제공합니다.

속성	값
초	0-59
의사록	0-59
시간	0-23
날짜	1-31
달	1-12 또는 JAN-DEC
요일	1-7 또는 SUN-SAT

스케줄러 엔드 포인트에서 지원하는 Quartz Cron 표현식의 몇 가지 예는 다음과 같습니다.

• ½ * * * * ? − 스케줄러가 매일 2 초마다 실행됨을 의미합니다.

• 0 0/5 16 ** ? − 스케줄러가 매일 오후 4 시부 터 오후 4시 55 분까지 5 분마다 실행됨을 의미합니다.

• 1 1 1 1, 5 * ? − 스케줄러가 매년 1 월 1 일과 4 월 1 일에 실행됨을 의미합니다.

예

다음 코드는 매초 "hi"메시지를 기록합니다.

<flow name = "cronFlow" doc:id = "ae257a5d-6b4f-4006-80c8-e7c76d2f67a0">
   <doc:name = "Scheduler" doc:id = "e7b6scheduler8ccb-c6d8-4567-87af-aa7904a50359">
      <scheduling-strategy>
         <cron expression = "* * * * * ?" timeZone = "America/Los_Angeles"/>
      </scheduling-strategy>
   </scheduler>
   <logger level = "INFO" doc:name = "Logger" 
      doc:id = "e2626dbb-54a9-4791-8ffa-b7c9a23e88a1" message = '"hi"'/>
</flow>

흐름 제어 (라우터)

Flow Control 구성 요소의 주요 작업은 입력 Mule 이벤트를 가져와 하나 이상의 개별 구성 요소 시퀀스로 라우팅하는 것입니다. 기본적으로 입력 Mule 이벤트를 다른 구성 요소 시퀀스로 라우팅합니다. 따라서 라우터라고도합니다. 선택 및 분산 수집 라우터는 흐름 제어 구성 요소에서 가장 많이 사용되는 라우터입니다.

초이스 라우터

이름에서 알 수 있듯이이 라우터는 DataWeave 로직을 적용하여 둘 이상의 경로 중 하나를 선택합니다. 앞에서 설명한 것처럼 각 경로는 Mule 이벤트 프로세서의 개별 시퀀스입니다. 메시지 콘텐츠를 평가하는 데 사용되는 DataWeave 식 집합에 따라 흐름을 통해 메시지를 동적으로 라우팅하는 라우터로 선택 라우터를 정의 할 수 있습니다.

Choice Router의 개략도

Choice 라우터 사용의 효과는 흐름 또는 네트워크에 조건부 처리를 추가하는 것과 같습니다. if/then/else대부분의 프로그래밍 언어에서 코드 블록. 다음은 세 가지 옵션이있는 Choice Router의 개략도입니다. 그중 하나는 기본 라우터입니다.

분산 수집 라우터

가장 많이 사용되는 또 다른 라우팅 이벤트 프로세서는 Scatter-Gather component. 이름에서 알 수 있듯이 분산 (복사) 및 수집 (통합)의 기본에 대해 작동합니다. 우리는 다음 두 가지 사항의 도움으로 작동을 이해할 수 있습니다.

• 먼저이 라우터는 Mule 이벤트를 두 개 이상의 병렬 경로에 복사 (Scatter)합니다. 조건은 각 경로가 하위 흐름과 같은 하나 이상의 이벤트 프로세서 시퀀스 여야한다는 것입니다. 이 경우 각 경로는 별도의 스레드를 사용하여 Mule 이벤트를 만듭니다. 모든 Mule 이벤트에는 자체 페이로드, 속성 및 변수가 있습니다.

• 다음으로,이 라우터는 각 경로에서 생성 된 Mule 이벤트를 수집 한 다음이를 새로운 Mule 이벤트로 통합합니다. 그런 다음이 통합 된 Mule 이벤트를 다음 이벤트 프로세서로 전달합니다. 여기서 조건은 SG 라우터가 모든 경로가 성공적으로 완료된 경우에만 통합 된 Mule 이벤트를 다음 이벤트 프로세서로 전달한다는 것입니다.

Scatter-Gather Router의 개략도

다음은 4 개의 이벤트 프로세서가있는 Scatter-Gather Router의 개략도입니다. 모든 경로를 순차적이 아닌 병렬로 실행합니다.

Scatter-Gather Router에 의한 오류 처리

첫째, Scatter-Gather 컴포넌트 내에서 생성 될 수있는 오류의 종류에 대한 지식이 있어야합니다. Scatter-Gather 구성 요소가 유형의 오류를 발생시키는 이벤트 프로세서 내에서 오류가 생성 될 수 있습니다.Mule: COMPOSITE_ERROR. 이 오류는 모든 경로가 실패하거나 완료된 후에 만 ​​SG 구성 요소에서 발생합니다.

이 오류 유형을 처리하려면 try scopeScatter-Gather 구성 요소의 각 경로에서 사용할 수 있습니다. 오류가 성공적으로 처리 된 경우try scope, 그러면 경로는 확실히 Mule 이벤트를 생성 할 수 있습니다.

변압기

Mule 이벤트의 일부를 설정하거나 제거하려는 경우 Transformer 구성 요소가 최선의 선택이라고 가정합니다. 변압기 구성 요소는 다음과 같은 유형입니다-

가변 변압기 제거

이름에서 알 수 있듯이이 구성 요소는 변수 이름을 가져와 Mule 이벤트에서 해당 변수를 제거합니다.

가변 변환기 제거 구성

아래 표는 변수 변환기 제거를 구성 할 때 고려해야 할 필드 이름과 설명을 보여줍니다.

Sr. 아니요	분야 및 설명
1	Display Name (doc:name) Mule 작업 흐름에서이 구성 요소의 고유 한 이름을 표시하도록이를 사용자 지정할 수 있습니다.
2	Name (variableName) 제거 할 변수의 이름을 나타냅니다.

페이로드 변압기 설정

의 도움으로 set-payload구성 요소에서 메시지의 리터럴 문자열 또는 DataWeave 표현식이 될 수있는 페이로드를 업데이트 할 수 있습니다. 복잡한 식이나 변환에는이 구성 요소를 사용하지 않는 것이 좋습니다. 다음과 같은 간단한 것에 사용할 수 있습니다.selections.

아래 표는 세트 페이로드 변환기를 구성하는 동안 고려해야 할 필드 이름과 설명을 보여줍니다.

들	용법	설명
값 (값)	필수	필드 값은 페이로드 설정에 필요합니다. 페이로드 설정 방법을 정의하는 리터럴 문자열 또는 DataWeave 표현식을 허용합니다. 예는 "일부 문자열"과 같습니다.
Mime 유형 (mimeType)	선택 과목	선택 사항이지만 메시지 페이로드에 할당 된 값의 MIME 유형을 나타냅니다. 예제는 텍스트 / 일반과 같습니다.
인코딩 (인코딩)	선택 과목	또한 선택 사항이지만 메시지 페이로드에 할당 된 값의 인코딩을 나타냅니다. 예제는 UTF-8과 같습니다.

XML 구성 코드를 통해 페이로드를 설정할 수 있습니다.

With Static Content − 다음 XML 구성 코드는 정적 콘텐츠를 사용하여 페이로드를 설정합니다.

<set-payload value = "{ 'name' : 'Gaurav', 'Id' : '2510' }" 
   mimeType = "application/json" encoding = "UTF-8"/>

With Expression Content − 다음 XML 구성 코드는 Expression 콘텐츠를 사용하여 페이로드를 설정합니다.

<set-payload value = "#['Hi' ++ ' Today is ' ++ now()]"/>

위의 예는 "Hi"라는 메시지 페이로드와 함께 오늘 날짜를 추가합니다.

가변 변압기 설정

의 도움으로 set variable구성 요소에서, 우리는 Mule 애플리케이션의 흐름 내에서 사용하기 위해 문자열, 메시지 페이로드 또는 속성 객체와 같은 단순한 리터럴 값이 될 수있는 값을 저장하는 변수를 생성하거나 업데이트 할 수 있습니다. 복잡한 식이나 변환에는이 구성 요소를 사용하지 않는 것이 좋습니다. 다음과 같은 간단한 것에 사용할 수 있습니다.selections.

설정 변수 변환기 구성

아래 표는 세트 페이로드 변환기를 구성하는 동안 고려해야 할 필드 이름과 설명을 보여줍니다.

들	용법	설명
변수 이름 (variableName)	필수	필수 필드이며 변수의 이름을 나타냅니다. 이름을 지정할 때 숫자, 문자 및 밑줄을 포함해야하는 것처럼 명명 규칙을 따르십시오.
값 (값)	필수	필드 값은 변수 설정에 필요합니다. 리터럴 문자열 또는 DataWeave 표현식을 허용합니다.
Mime 유형 (mimeType)	선택 과목	선택 사항이지만 변수의 MIME 유형을 나타냅니다. 예제는 텍스트 / 일반과 같습니다.
인코딩 (인코딩)	선택 과목	또한 선택 사항이지만 변수의 인코딩을 나타냅니다. 예는 ISO 10646 / Unicode (UTF-8)와 같습니다.

예

아래 예제는 변수를 메시지 페이로드로 설정합니다.

Variable Name = msg_var
Value = payload in Design center and #[payload] in Anypoint Studio

마찬가지로, 아래 예제는 변수를 메시지 페이로드로 설정합니다.

Variable Name = msg_var
Value = attributes in Design center and #[attributes] in Anypoint Studio.

REST 웹 서비스

REST의 전체 형태는 HTTP와 바인딩 된 Representational State Transfer입니다. 따라서 웹에서만 사용할 수 있도록 응용 프로그램을 디자인하려면 REST가 가장 좋은 옵션입니다.

RESTful 웹 서비스 사용

다음 예에서는 REST 구성 요소와 Mule Soft에서 제공하는 American Flights details라는 공용 RESTful 서비스를 사용합니다. 다양한 세부 사항이 있지만 GET을 사용할 것입니다.http://training-american-ws.cloudhub.io/api/flights모든 비행 세부 정보를 반환합니다. 앞서 논의했듯이 REST는 HTTP와 바인딩되므로이 애플리케이션에 대해 하나는 Listener이고 다른 하나는 요청 인 두 개의 HTTP 구성 요소가 필요합니다. 아래 스크린 샷은 HTTP 리스너의 구성을 보여줍니다.

인수 구성 및 전달

HTTP 요청에 대한 구성은 다음과 같습니다.

이제 작업 공간 흐름에 따라 로거를 사용하여 아래와 같이 구성 할 수 있습니다.

메시지 탭에서 페이로드를 문자열로 변환하는 코드를 작성합니다.

응용 프로그램 테스트

이제 응용 프로그램을 저장하고 실행하고 POSTMAN으로 이동하여 아래와 같이 최종 출력을 확인하십시오.

REST 구성 요소를 사용하여 비행 세부 정보를 제공하는 것을 볼 수 있습니다.

SOAP 구성 요소

SOAP의 전체 형식은 다음과 같습니다. Simple Object Access Protocol. 기본적으로 웹 서비스 구현에서 정보를 교환하기위한 메시징 프로토콜 사양입니다. 다음으로 Anypoint Studio에서 SOAP API를 사용하여 웹 서비스를 통해 정보에 접근 할 것입니다.

SOAP 기반 웹 서비스 사용

이 예에서는 국가 정보와 관련된 서비스를 유지하는 국가 정보 서비스라는 이름의 공용 SOAP 서비스를 사용합니다. WSDL 주소는 다음과 같습니다.http://www.oorsprong.org/websamples.countryinfo/countryinfoservice.wso?WSDL

먼저 아래 그림과 같이 Mule Palette에서 캔버스에 SOAP 소비를 드래그해야합니다.

인수 구성 및 전달

다음으로, 위의 예에서 아래와 같이 HTTP 요청을 구성해야합니다.

이제 다음과 같이 웹 서비스 소비자를 구성해야합니다.

WSDL Location의 위치에서 위에서 제공 한 WSDL의 웹 주소를 제공해야합니다 (이 예의 경우). 웹 주소를 제공하면 Studio는 자체적으로 서비스, 포트 및 주소를 검색합니다. 수동으로 제공 할 필요는 없습니다.

웹 서비스에서 응답 전송

이를 위해 Mule 흐름에 로거를 추가하고 아래와 같이 페이로드를 제공하도록 구성해야합니다.

응용 프로그램 테스트

애플리케이션을 저장하고 실행하고 Google 크롬으로 이동하여 최종 출력을 확인합니다. 유형http://localhist:8081/helloSOAP (이 예의 경우) 아래 스크린 샷과 같이 코드로 국가 이름이 표시됩니다.

새로운 Mule 오류 처리는 Mule 4에서 수행 된 가장 크고 중요한 변경 사항 중 하나입니다. 새로운 오류 처리는 복잡해 보일 수 있지만 더 좋고 효율적입니다. 이 장에서는 Mule 오류의 구성 요소, 오류 유형, Mule 오류의 범주 및 Mule 오류 처리를위한 구성 요소에 대해 설명합니다.

노새 오류의 구성 요소

Mule 오류는 Mule 예외 실패의 결과입니다.

기술

문제에 대한 설명을 제공하는 Mule 오류의 중요한 구성 요소입니다. 그 표현은 다음과 같습니다-

#[error.description]

유형

Mule 오류의 유형 구성 요소는 문제를 특성화하는 데 사용됩니다. 또한 오류 처리기 내에서 라우팅을 허용합니다. 그 표현은 다음과 같습니다-

#[error.errorType]

원인

Mule 오류의 원인 구성 요소는 실패를 일으키는 기본 Java throwable을 제공합니다. 그 표현은 다음과 같습니다-

#[error.cause]

메시지

Mule 오류 의 메시지 구성 요소는 오류에 대한 선택적 메시지를 표시합니다. 그 표현은 다음과 같습니다-

#[error.errorMessage]

아동 오류

Mule 오류 의 자식 오류 구성 요소는 내부 오류의 선택적 컬렉션을 제공합니다. 이러한 내부 오류는 주로 Scatter-Gather와 같은 요소에서 집계 된 경로 오류를 제공하는 데 사용됩니다. 그 표현은 다음과 같습니다-

#[error.childErrors]

예

401 상태 코드로 HTTP 요청이 실패한 경우 Mule 오류는 다음과 같습니다.

Description: HTTP GET on resource ‘http://localhost:8181/TestApp’ 
failed: unauthorized (401)
Type: HTTP:UNAUTHORIZED
Cause: a ResponseValidatorTypedException instance
Error Message: { "message" : "Could not authorize the user." }

Sr.NO	오류 유형 및 설명
1	TRANSFORMATION 이 오류 유형은 값을 변환하는 동안 오류가 발생했음을 나타냅니다. 변환은 DataWeave 변환이 아니라 Mule 런타임 내부 변환입니다.
2	EXPRESSION 이러한 종류의 오류 유형은 식을 평가하는 동안 오류가 발생했음을 나타냅니다.
삼	VALIDATION 이러한 종류의 오류 유형은 유효성 검사 오류가 발생했음을 나타냅니다.
4	DUPLICATE_MESSAGE 메시지가 두 번 처리 될 때 발생하는 일종의 유효성 검사 오류입니다.
5	REDELIVERY_EXHAUSTED 이러한 종류의 오류 유형은 소스에서 메시지를 재 처리하려는 최대 시도가 소진되었을 때 발생합니다.
6	CONNECTIVITY 이 오류 유형은 연결을 설정하는 동안 문제가 있음을 나타냅니다.
7	ROUTING 이 오류 유형은 메시지를 라우팅하는 동안 오류가 발생했음을 나타냅니다.
8	SECURITY 이 오류 유형은 보안 오류가 발생했음을 나타냅니다. 예를 들어 잘못된 자격 증명을 받았습니다.
9	STREAM_MAXIMUM_SIZE_EXCEEDED 이 오류 유형은 스트림에 허용되는 최대 크기가 소진되었을 때 발생합니다.
10	TIMEOUT 메시지를 처리하는 동안 시간 초과를 나타냅니다.
11	UNKNOWN 이 오류 유형은 예기치 않은 오류가 발생했음을 나타냅니다.
12	SOURCE 흐름 소스에서 오류가 발생했음을 나타냅니다.
13	SOURCE_RESPONSE 성공적인 응답을 처리하는 동안 플로우 소스에서 오류가 발생했음을 나타냅니다.

위의 예에서 mule error 의 메시지 구성 요소를 볼 수 있습니다 .

오류 유형

그 특성의 도움으로 오류 유형을 이해합시다-

• Mule 오류 유형의 첫 번째 특징은 a namespace and an identifier. 이를 통해 도메인에 따라 유형을 구별 할 수 있습니다. 위의 예에서 오류 유형은 다음과 같습니다.HTTP: UNAUTHORIZED.

• 두 번째로 중요한 특징은 오류 유형이 상위 유형을 가질 수 있다는 것입니다. 예를 들어, 오류 유형HTTP: UNAUTHORIZED 있다 MULE:CLIENT_SECURITY 차례로 부모라는 이름을 가진 부모로 MULE:SECURITY. 이 특성은 오류 유형을보다 글로벌 항목의 사양으로 설정합니다.

오류 유형의 종류

다음은 모든 오류가 속하는 범주입니다.

어떤

이 범주의 오류는 흐름에서 발생할 수있는 오류입니다. 그들은 그렇게 심각하지 않으며 쉽게 다룰 수 있습니다.

위독한

이 범주의 오류는 처리 할 수없는 심각한 오류입니다. 다음은이 범주의 오류 유형 목록입니다.

Sr.NO	오류 유형 및 설명
1	OVERLOAD 이 오류 유형은 과부하 문제로 인해 오류가 발생했음을 나타냅니다. 이 경우 실행이 거부됩니다.
2	FATAL_JVM_ERROR 이러한 종류의 오류 유형은 치명적인 오류의 발생을 나타냅니다. 예를 들어 스택 오버플로입니다.

CUSTOM 오류 유형

CUSTOM 오류 유형은 당사가 정의한 오류입니다. 매핑 할 때 또는 오류를 일으킬 때 정의 할 수 있습니다. Mule 애플리케이션 내의 다른 기존 오류 유형과 구별하기 위해 이러한 오류 유형에 특정 사용자 정의 네임 스페이스를 제공해야합니다. 예를 들어 HTTP를 사용하는 Mule 응용 프로그램에서는 HTTP를 사용자 지정 오류 유형으로 사용할 수 없습니다.

노새 오류 범주

넓은 의미에서 Mule의 오류는 두 가지 범주로 나눌 수 있습니다. Messaging Errors and System Errors.

메시징 오류

이 Mule 오류 범주는 Mule 흐름과 관련이 있습니다. Mule 흐름 내에서 문제가 발생할 때마다 Mule은 메시징 오류를 발생시킵니다. 우리는 설정할 수 있습니다On Error 이러한 Mule 오류를 처리하기 위해 오류 처리기 구성 요소 내부의 구성 요소.

시스템 오류

시스템 오류는 시스템 수준에서 발생하는 예외를 나타냅니다. Mule 이벤트가 없으면 시스템 오류 처리기가 시스템 오류를 처리합니다. 다음과 같은 종류의 예외는 시스템 오류 처리기에 의해 처리됩니다.

• 응용 프로그램 시작 중에 발생하는 예외입니다.
• 외부 시스템에 대한 연결이 실패 할 때 발생하는 예외입니다.

시스템 오류가 발생하면 Mule은 등록 된 리스너에게 오류 알림을 보냅니다. 또한 오류를 기록합니다. 반면에 Mule은 연결 실패로 인해 오류가 발생한 경우 재 연결 전략을 실행합니다.

뮬 오류 처리

Mule은 오류를 처리하기 위해 다음과 같은 두 가지 오류 처리기를 가지고 있습니다.

오류시 오류 처리기

첫 번째 Mule 오류 처리기는 처리 할 수있는 오류 유형을 정의하는 On-Error 구성 요소입니다. 앞에서 설명한대로 범위와 같은 오류 처리기 구성 요소 내에서 오류 발생 구성 요소를 구성 할 수 있습니다. 각 Mule 흐름에는 오류 처리기가 하나만 포함되어 있지만이 오류 처리기는 필요한만큼 On-Error 범위를 포함 할 수 있습니다. On-Error 구성 요소의 도움으로 흐름 내에서 Mule 오류를 처리하는 단계는 다음과 같습니다.

• 첫째, Mule 흐름에서 오류가 발생할 때마다 정상적인 흐름 실행이 중지됩니다.

• 다음으로 프로세스는 Error Handler Component 이미 가지고있는 On Error component 오류 유형 및 표현식을 일치시킵니다.

• 마지막으로 오류 처리기 구성 요소는 오류를 첫 번째 On Error scope 오류와 일치합니다.

다음은 Mule에서 지원하는 두 가지 유형의 On-Error 구성 요소입니다.

오류 발생시 전파

On-Error Propagate 구성 요소가 실행되지만 오류를 다음 수준으로 전파하고 소유자의 실행을 중단합니다. 트랜잭션이 처리되는 경우 롤백됩니다.On Error Propagate 구성 요소.

오류시 계속

On-Error Propagate 구성 요소와 마찬가지로 On-Error Continue 구성 요소도 트랜잭션을 실행합니다. 유일한 조건은 소유자가 실행을 성공적으로 완료 한 경우이 구성 요소가 소유자의 결과로 실행 결과를 사용한다는 것입니다. On-Error Continue 구성 요소에 의해 처리되는 경우 트랜잭션이 커밋됩니다.

범위 구성 요소 시도

Try Scope는 Mule 4에서 사용할 수있는 많은 새로운 기능 중 하나입니다. 예외가 될 가능성이있는 코드를 묶어 두었던 JAVA의 try 블록과 유사하게 작동하므로 전체 코드를 깨지 않고 처리 할 수 ​​있습니다.

Try Scope에서 하나 이상의 Mule 이벤트 프로세서를 래핑 할 수 있으며 그 후 try scope는 이러한 이벤트 프로세서에서 발생한 모든 예외를 포착하고 처리합니다. try 범위의 주요 작업은 전체 흐름 대신 내부 구성 요소에서 오류 처리를 지원하는 자체 오류 처리 전략을 중심으로 이루어집니다. 그렇기 때문에 흐름을 별도의 흐름으로 추출 할 필요가 없습니다.

Example

다음은 try 범위 사용의 예입니다.

트랜잭션 처리를위한 try 범위 구성

아시다시피 트랜잭션은 부분적으로 실행되어서는 안되는 일련의 작업입니다. 트랜잭션 범위 내의 모든 작업은 동일한 스레드에서 실행되며 오류가 발생하면 롤백 또는 커밋으로 이어져야합니다. 다음과 같은 방법으로 try 범위를 구성하여 자식 작업을 트랜잭션으로 처리 할 수 ​​있습니다.

• INDIFFERENT [Default]− try 블록에서이 구성을 선택하면 자식 작업이 트랜잭션으로 처리되지 않습니다. 이 경우 오류로 인해 롤백이나 커밋이 발생하지 않습니다.

• ALWAYS_BEGIN − 스코프가 실행될 때마다 새로운 트랜잭션이 시작됨을 나타냅니다.

• BEGIN_OR_JOIN− 현재 처리중인 플로우가 이미 트랜잭션을 시작한 경우 참여 함을 나타냅니다. 그렇지 않으면 새로 시작하십시오.

모든 프로젝트의 경우 예외에 대한 사실은 예외가 발생할 수밖에 없다는 것입니다. 그렇기 때문에 시스템 / 애플리케이션이 일관되지 않은 상태에 남아 있지 않도록 예외를 포착, 분류 및 처리하는 것이 중요합니다. 모든 Mule 애플리케이션에 암시 적으로 적용되는 기본 예외 전략이 있습니다. 보류중인 트랜잭션을 자동으로 롤백하는 것이 기본 예외 전략입니다.

뮬의 예외

예외 처리에 대해 자세히 알아보기 전에 개발자가 예외 처리기를 설계 할 때 가져야하는 세 가지 기본 질문과 함께 어떤 종류의 예외가 발생할 수 있는지 이해해야합니다.

어떤 교통 수단이 중요합니까?

이 질문은 모든 전송이 초국적 성을 지원하지 않기 때문에 예외 처리기를 설계하기 전에 충분한 관련성을 가지고 있습니다.

File 또는 HTTP거래를 지원하지 않습니다. 그렇기 때문에 이러한 경우 예외가 발생하면 수동으로 관리해야합니다.

Databases지원 거래. 이 경우 예외 처리기를 디자인하는 동안 데이터베이스 트랜잭션이 자동으로 롤백 될 수 있다는 점을 염두에 두어야합니다 (필요한 경우).

의 경우 REST APIs, 올바른 HTTP 상태 코드를 반환해야한다는 점을 명심해야합니다. 예를 들어 리소스를 찾을 수없는 경우 404입니다.

사용할 메시지 교환 패턴은 무엇입니까?

예외 처리기를 설계 할 때 메시지 교환 패턴에주의해야합니다. 동기식 (요청-응답) 또는 비동기식 (fire-forget) 메시지 패턴이있을 수 있습니다.

Synchronous message pattern 요청-응답 형식을 기반으로합니다. 즉,이 패턴은 응답을 예상하고 응답이 반환되거나 시간 초과가 발생할 때까지 차단됩니다.

Asynchronous message pattern 이 패턴은 요청이 궁극적으로 처리 될 것이라고 가정하는 fire-forget 형식을 기반으로합니다.

어떤 유형의 예외입니까?

매우 간단한 규칙은 유형에 따라 예외를 처리한다는 것입니다. 예외가 시스템 / 기술 문제 또는 비즈니스 문제로 인한 것인지 아는 것이 매우 중요합니까?

예외가 발생했습니다. system/technical issue (예 : 네트워크 중단) 재시도 메커니즘에 의해 자동으로 처리되어야합니다.

반면에 예외가 발생했습니다. by a business issue (잘못된 데이터와 같은) 재시도 메커니즘을 적용하여 해결해서는 안됩니다. 근본적인 원인을 수정하지 않고 재 시도하는 것은 유용하지 않기 때문입니다.

예외를 분류하는 이유는 무엇입니까?

모든 예외가 동일하지 않다는 것을 알고 있으므로 예외를 분류하는 것이 매우 중요합니다. 상위 수준에서 예외는 다음 두 가지 유형으로 분류 할 수 있습니다.

비즈니스 예외

비즈니스 예외가 발생하는 주된 이유는 잘못된 데이터 또는 잘못된 프로세스 흐름입니다. 이러한 종류의 예외는 일반적으로 본질적으로 재 시도 할 수 없으므로 구성하는 것이 좋지 않습니다.rollback. 신청도retry근본적인 원인을 수정하지 않고 재 시도하는 것은 유용하지 않기 때문에 메커니즘이 의미가 없습니다. 이러한 예외를 처리하려면 처리가 즉시 중지되고 예외가 배달 못한 편지 대기열에 대한 응답으로 다시 전송되어야합니다. 작업에도 알림을 보내야합니다.

비업무 예외

비업무 예외가 발생하는 주된 이유는 시스템 문제 또는 기술 문제입니다. 이러한 종류의 예외는 본질적으로 재 시도 할 수 있으므로 구성하는 것이 좋습니다.retry 이러한 예외를 해결하기위한 메커니즘입니다.

예외 처리 전략

Mule에는 다음과 같은 다섯 가지 예외 처리 전략이 있습니다.

기본 예외 전략

Mule은이 전략을 Mule 흐름에 암시 적으로 적용합니다. 흐름의 모든 예외를 처리 할 수 ​​있지만 catch, Choice 또는 Rollback 예외 전략을 추가하여 재정의 할 수도 있습니다. 이 예외 전략은 보류중인 트랜잭션을 롤백하고 예외도 기록합니다. 이 예외 전략의 중요한 특징은 트랜잭션이없는 경우 예외도 기록한다는 것입니다.

기본 전략 인 Mule은 흐름에서 오류가 발생할 때이를 구현합니다. AnyPoint studio에서는 구성 할 수 없습니다.

롤백 예외 전략

오류를 수정할 수있는 해결책이 없다면 어떻게해야할까요? 해결책은 메시지를 재 처리하기 위해 상위 흐름의 인바운드 커넥터로 메시지를 보내는 것과 함께 트랜잭션을 롤백하는 롤백 예외 전략을 사용하는 것입니다. 이 전략은 메시지를 다시 처리 할 때도 매우 유용합니다.

Example

이 전략은 자금이 당좌 / 저축 계좌에 입금되는 은행 거래에 적용될 수 있습니다. 여기서 롤백 예외 전략을 구성 할 수 있습니다. 트랜잭션 중에 오류가 발생하는 경우이 전략은 메시지를 처음으로 롤백하여 처리를 다시 시도하기 때문입니다.

예외 전략 포착

이 전략은 부모 흐름 내에서 throw되는 모든 예외를 포착합니다. 부모 흐름에서 발생하는 모든 예외를 처리하여 Mule의 기본 예외 전략을 재정의합니다. 예외 포착 전략을 사용하여 예외가 인바운드 커넥터 및 상위 플로우로 전파되는 것을 방지 할 수 있습니다.

이 전략은 또한 예외가 발생할 때 흐름에 의해 처리 된 트랜잭션이 롤백되지 않도록합니다.

Example

이 전략은 대기열에서 메시지를 처리하는 흐름이있는 항공편 예약 시스템에 적용 할 수 있습니다. 메시지 보강 기는 좌석 할당을 위해 메시지에 속성을 추가 한 다음 메시지를 다른 대기열로 보냅니다.

이제이 흐름에서 오류가 발생하면 메시지에서 예외가 발생합니다. 여기서 예외 포착 전략은 적절한 메시지가있는 헤더를 추가하고 해당 메시지를 흐름에서 다음 대기열로 푸시 할 수 있습니다.

선택 예외 전략

메시지 내용에 따라 예외를 처리하려는 경우 선택 예외 전략이 최선의 선택이 될 것입니다. 이 예외 전략의 작동은 다음과 같습니다.

• 먼저 부모 흐름 내에서 throw 된 모든 예외를 포착합니다.
• 다음으로 메시지 내용과 예외 유형을 확인합니다.
• 마지막으로 메시지를 적절한 예외 전략으로 라우팅합니다.

선택 예외 전략 내에 정의 된 Catch 또는 Rollback과 같은 둘 이상의 예외 전략이 있습니다. 이 예외 전략에 정의 된 전략이없는 경우 메시지를 기본 예외 전략으로 라우팅합니다. 커밋 또는 롤백을 수행하거나 활동을 소비하지 않습니다.

참조 예외 전략

이는 별도의 구성 파일에 정의 된 공통 예외 전략을 나타냅니다. 메시지에서 예외가 발생하는 경우이 예외 전략은 전역 catch, 롤백 또는 선택 예외 전략에 정의 된 오류 처리 매개 변수를 참조합니다. 선택 예외 전략과 마찬가지로 커밋 또는 롤백을 수행하거나 활동을 소비하지 않습니다.

단위 테스트는 소스 코드의 개별 단위가 사용에 적합한 지 여부를 결정하기 위해 테스트 할 수있는 방법이라는 것을 알고 있습니다. Java 프로그래머는 Junit 프레임 워크를 사용하여 테스트 케이스를 작성할 수 있습니다. 마찬가지로 MuleSoft에는 API 및 통합에 대한 자동화 된 테스트 케이스를 작성할 수있는 MUnit이라는 프레임 워크도 있습니다. 지속적인 통합 / 배포 환경에 적합합니다. MUnit 프레임 워크의 가장 큰 장점 중 하나는 Maven 및 Surefire와 통합 할 수 있다는 것입니다.

MUnit의 특징

다음은 Mule MUnit 테스트 프레임 워크의 매우 유용한 기능 중 일부입니다.

• MUnit 프레임 워크에서는 Mule 코드와 Java 코드를 사용하여 Mule 테스트를 만들 수 있습니다.

• Anypoint Studio 내에서 그래픽 또는 XML로 Mule 앱과 API를 설계하고 테스트 할 수 있습니다.

• MUnit을 사용하면 테스트를 기존 CI / CD 프로세스에 쉽게 통합 할 수 있습니다.

• 자동 생성 된 테스트 및 커버리지 보고서를 제공합니다. 따라서 수동 작업이 최소화됩니다.

• 또한 로컬 DB / FTP / 메일 서버를 사용하여 CI 프로세스를 통해 테스트를보다 쉽게 ​​이식 할 수 있습니다.

• 테스트를 활성화하거나 비활성화 할 수 있습니다.

• 플러그인으로 MUnit 프레임 워크를 확장 할 수도 있습니다.

• 이를 통해 메시지 프로세서 호출을 확인할 수 있습니다.

• MUnit 테스트 프레임 워크의 도움으로 엔드 포인트 커넥터와 플로우 인바운드 엔드 포인트를 비활성화 할 수 있습니다.

• Mule 스택 추적으로 오류 보고서를 확인할 수 있습니다.

Mule MUnit 테스트 프레임 워크의 최신 릴리스

MUnit 2.1.4는 Mule MUnit 테스트 프레임 워크의 최신 릴리스입니다. 다음과 같은 하드웨어 및 소프트웨어 요구 사항이 필요합니다.

• MS Windows 8 이상
• Apple Mac OS X 10.10 이상
• Linux
• 자바 8
• 메이븐 3.3.3, 3.3.9, 3.5.4, 3.6.0

Mule 4.1.4 및 Anypoint Studio 7.3.0과 호환됩니다.

MUnit 및 Anypoint Studio

논의한 바와 같이 MUnit은 Anypoint 스튜디오에 완전히 통합되어 있으며 Mule 앱과 API를 그래픽으로 또는 Anypoint 스튜디오 내에서 XML로 디자인하고 테스트 할 수 있습니다. 즉, Anypoint Studio의 그래픽 인터페이스를 사용하여 다음을 수행 할 수 있습니다.

• MUnit 테스트 생성 및 디자인
• 테스트 실행
• 테스트 결과 및 커버리지 보고서보기
• 테스트 디버깅 용

이제 각 작업에 대해 하나씩 논의 해 보겠습니다.

MUnit 테스트 생성 및 설계

새 프로젝트를 시작하면 자동으로 새 폴더가 추가됩니다. src/test/munit우리 프로젝트에. 예를 들어, 우리는 새로운 Mule 프로젝트를 시작했습니다.test_munit, 아래 이미지에서 볼 수 있으며, 우리 프로젝트 아래에 위에서 언급 한 폴더를 추가합니다.

이제 새 프로젝트를 시작하면 Anypoint Studio에서 새 MUnit 테스트를 만드는 두 가지 기본 방법이 있습니다.

• By Right-Clicking the Flow −이 방법에서는 특정 흐름을 마우스 오른쪽 버튼으로 클릭하고 드롭 다운 메뉴에서 MUnit을 선택해야합니다.

• By Using the Wizard−이 방법에서는 마법사를 사용하여 테스트를 생성해야합니다. 작업 공간의 모든 흐름에 대한 테스트를 만들 수 있습니다.

특정 흐름에 대한 테스트를 만들기 위해 '흐름을 마우스 오른쪽 버튼으로 클릭'하는 방법을 사용합니다.

먼저 다음과 같이 작업 공간에 흐름을 만들어야합니다.

이제이 흐름을 마우스 오른쪽 단추로 클릭하고 MUnit을 선택하여 아래 표시된대로이 흐름에 대한 테스트를 만듭니다.

흐름이있는 XML 파일의 이름을 따서 명명 된 새 테스트 스위트를 생성합니다. 이 경우test_munit-test-suite 아래에 표시된대로 새 테스트 스위트의 이름입니다.

다음은 위의 메시지 흐름에 대한 XML 편집기입니다.

이제 우리는 MUnit 메시지 프로세서를 Mule Palette에서 드래그하여 테스트 스위트로 이동합니다.

마법사를 통해 테스트를 생성하려면 다음을 따르십시오. File → New → MUnit 다음 MUnit 테스트 스위트로 연결됩니다.

테스트 구성

Mule 4에는 두 개의 새로운 섹션이 있습니다. MUnit 과 MUnit Tools, 집합 적으로 모든 MUnit 메시지 프로세서가 있습니다. MUnit 테스트 영역에서 메시지 프로세서를 드래그 할 수 있습니다. 아래 스크린 샷에 나와 있습니다.

이제 Anypoint Studio에서 슈트 또는 테스트의 구성을 편집하려면 아래 단계를 따라야합니다.

Step 1

다음으로 이동 Package Explorer 마우스 오른쪽 버튼으로 .xml file스위트 또는 테스트를 위해. 그런 다음Properties.

Step 2

이제 속성 창에서 Run/Debug Setting에스. 이 클릭 후New.

Step 3

마지막 단계에서 MUnit 아래에 Select Configuration Type 창을 클릭 한 다음 OK.

테스트 실행

테스트뿐만 아니라 테스트 스위트도 실행할 수 있습니다. 먼저 테스트 스위트를 실행하는 방법을 살펴 보겠습니다.

테스트 스위트 실행

테스트 스위트를 실행하려면 테스트 스위트가있는 Mule Canvas의 빈 부분을 마우스 오른쪽 버튼으로 클릭합니다. 드롭 다운 메뉴가 열립니다. 이제Run MUnit suite 아래와 같이-

나중에 콘솔에서 출력을 볼 수 있습니다.

테스트 실행

특정 테스트를 실행하려면 특정 테스트를 선택하고 마우스 오른쪽 버튼을 클릭해야합니다. 테스트 스위트를 실행하는 동안 얻은 것과 동일한 드롭 다운 메뉴가 표시됩니다. 이제Run MUnit Test 아래 표시된 옵션-

콘솔에서 출력을 볼 수 있습니다.

테스트 결과보기 및 분석

Anypoint Studio는 MUnit 테스트 결과를 MUnit tab왼쪽 탐색기 창의 아래 그림과 같이 녹색으로 성공한 테스트와 빨간색으로 실패한 테스트를 찾을 수 있습니다.

커버리지 보고서를보고 테스트 결과를 분석 할 수 있습니다. Coverage Report의 주요 기능은 MUnit 테스트 세트에서 성공적으로 실행 된 Mule 애플리케이션의 양에 대한 지표를 제공하는 것입니다. MUnit 적용 범위는 기본적으로 실행되는 MUnit 메시지 프로세서의 양을 기반으로합니다. MUnit 커버리지 보고서는 다음에 대한 메트릭을 제공합니다-

• 응용 프로그램 전체 범위
• 리소스 범위
• 흐름 범위

커버리지 보고서를 받으려면 아래와 같이 MUnit 탭에서 '보고서 생성'을 클릭해야합니다.

테스트 디버깅

테스트뿐만 아니라 테스트 스위트도 디버깅 할 수 있습니다. 먼저 테스트 스위트를 디버그하는 방법을 살펴 보겠습니다.

테스트 스위트 디버깅

테스트 스위트를 디버깅하려면 테스트 스위트가있는 Mule Canvas의 빈 부분을 마우스 오른쪽 버튼으로 클릭하십시오. 드롭 다운 메뉴가 열립니다. 이제Debug MUnit Suite 아래 이미지와 같이-

그런 다음 콘솔에서 출력을 볼 수 있습니다.

테스트 디버깅

특정 테스트를 디버깅하려면 특정 테스트를 선택하고 마우스 오른쪽 버튼을 클릭해야합니다. 테스트 스위트를 디버깅하는 동안 얻은 것과 동일한 드롭 다운 메뉴가 표시됩니다. 이제Debug MUnit Test선택권. 아래 스크린 샷에 나와 있습니다.