기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
AWS 현대화된 애플리케이션의 블루 에이지 구조
이 문서에서는 개발자가 다음과 같은 다양한 작업을 수행할 수 있도록 AWS 메인프레임 현대화 리팩토링 도구를 사용하여 현대화된 애플리케이션의 구조에 대한 세부 정보를 제공합니다.
-
애플리케이션을 원활하게 탐색합니다.
-
현대화된 애플리케이션에서 직접적으로 호출할 수 있는 사용자 지정 프로그램 개발
-
현대화된 애플리케이션을 안전하게 리팩터링합니다.
다음 사항에 대한 기본 지식이 이미 있다고 가정합니다.
-
레코드, 데이터 세트 및 레코드에 대한 액세스 모드 (인덱스, 순차), 실행 단위, jcl 스크립트, 개념 등과 같은 기존의 일반적인 코딩 개념이 VSAM 여기에 해당합니다. CICS
-
스프링 프레임워크
를 사용한 java 코딩. -
문서 전체에서 가독성을 높이기
short class names를 사용합니다. 자세한 내용은 AWS Blu Age 런타임 요소의 해당 정식 이름 검색 및 타사 요소의 해당 정규화된 이름 AWS Blu Age 정식 이름 매핑 타사의 완전한 자격을 갖춘 이름 매핑 검색하기를 참조하십시오. -
모든 아티팩트와 샘플은 샘플/애플리케이션의 현대화 프로세스 출력에서 가져온 것입니다. COBOL CICS CardDemo
아티팩트 조직
AWS Blu Age 현대화 애플리케이션은 서버에 배포할 수 있는 Java 웹 애플리케이션 (.war) 으로 패키징됩니다. JEE 일반적으로 서버는 Tomcat
war는 여러 구성 요소 아티팩트(.jar)를 집계합니다. 각 jar는 현대화 프로세스의 결과물인 전용 자바 프로젝트를(maven
기본 조직은 다음 구조를 취합니다.
-
엔티티 프로젝트: 비즈니스 모델 및 컨텍스트 요소를 포함합니다. 프로젝트 이름은 일반적으로 “-entities”로 끝납니다. 일반적으로 특정 레거시 COBOL 프로그램의 경우 이는 I/O 섹션 (데이터 세트) 및 데이터 부서의 현대화에 해당합니다. 2개 이상의 엔티티 프로젝트가 있을 수 있습니다.
-
서비스 프로젝트: 레거시 비즈니스 로직 현대화 요소가 포함되어 있습니다. 일반적으로 COBOL 프로그램의 프로시저 분할입니다. 프로젝트를 두 개 이상 선택할 수 있습니다.
-
유틸리티 프로젝트: 다른 프로젝트에서 사용하는 공유 공통 도구 및 유틸리티를 포함합니다.
-
웹 프로젝트: 해당하는 경우 UI 관련 요소의 현대화가 포함됩니다. 일괄 전용 현대화 프로젝트에는 사용되지 않습니다. 이러한 UI 요소는 CICS BMS 맵, IMS MFS 구성 요소 및 기타 메인프레임 UI 소스에서 가져올 수 있습니다. 프로젝트를 두 개 이상 선택할 수 있습니다.
엔티티 프로젝트 콘텐츠
참고
다음 설명은 PL/I 현대화 COBOL 출력에만 적용됩니다. RPG현대화 결과는 다른 레이아웃을 기반으로 합니다.
리팩터링이 발생하기 전에 엔티티 프로젝트의 패키지 조직을 현대화된 프로그램에 연결합니다. 다음 두 가지 방법으로 이 작업을 수행할 수 있습니다. 선호하는 방법은 코드 생성 메커니즘을 트리거하기 전에 작동하는 리팩터링 툴박스를 사용하는 것입니다. 이는 고급 작업이며 BluAge 교육에 설명되어 있습니다. 자세한 내용은 리팩터링
프로그램 관련 클래스
현대화된 각 프로그램은 비즈니스.컨텍스트 패키지와 비즈니스.모델 패키지라는 두 개의 패키지와 관련되어 있습니다.
-
base package.program.business.contextbusiness.context 하위 패키지에는 구성 클래스와 컨텍스트 클래스라는 두 개의 클래스가 포함되어 있습니다.
-
프로그램의 구성 클래스 하나는 해당 프로그램에 대한 특정 구성 세부 정보(예: 문자 기반 데이터 요소를 나타내는 데 사용할 문자 집합, 데이터 구조 요소를 채우는 데 사용되는 기본 바이트 값 등)를 포함합니다. 클래스 이름은 “구성”으로 끝납니다.
@org.springframework.context.annotation.Configuration주석으로 표시되며 올바른 설정Configuration객체를 반환해야 하는 단일 메서드가 포함되어 있습니다.
-
하나의 컨텍스트 클래스는 프로그램 서비스 클래스(아래 참조) 와 모델 하위 패키지(아래 참조) 의 데이터 구조(
Record) 및 데이터 세트(File)를 연결하는 다리 역할을 합니다. 클래스 이름은 “Context”로 끝나며RuntimeContext클래스의 하위 클래스입니다.
-
-
base package.program.business.model모델 하위 패키지에는 해당 프로그램이 사용할 수 있는 모든 데이터 구조가 들어 있습니다. 예를 들어, 01 수준 COBOL 데이터 구조는 모델 하위 패키지의 클래스에 해당합니다 (하위 수준 데이터 구조는 고유한 01 수준 구조의 속성임). 01 데이터 구조를 현대화하는 방법은 AWS Blu Age의 데이터 단순화기란 무엇입니까? 섹션을 참조하세요.
모든 RecordEntity 클래스는 비즈니스 레코드 표현에 대한 액세스를 나타내는 클래스를 확장합니다. 일부 레코드는 File에 묶여 있기 때문에 특별한 용도를 가지고 있습니다. Recorda와 a 사이의 File 바인딩은 파일 객체를 만들 때 컨텍스트 클래스에 있는 대응* FileHandler 메서드에서 이루어집니다. 예를 들어, 다음 목록은 TransactfileFile File 가 transactFile Record (모델 하위 패키지에서) 에 바인딩되는 방법을 보여줍니다.
서비스 프로젝트 내용
모든 서비스 프로젝트에는 아키텍처의 백본으로 사용되는 전용 SpringbootSpringBootLauncher 이름이 지정된 클래스를 통해 구체화됩니다.
이 수업의 주요 역할은 다음과 같습니다.
-
프로그램 클래스와 관리되는 리소스(데이터 소스/트랜잭션 관리자/데이터 세트 매핑/등...) 를 연결합니다.
-
ConfigurableApplicationContext를 프로그램에 제공합니다. -
스프링 컴포넌트로 표시된 모든 클래스 검색(
@Component). -
프로그램이
ProgramRegistry에 제대로 등록되었는지 확인하세요. 이 등록을 담당하는 initialize 메서드를 참조하세요.
프로그램 관련 아티팩트
사전 리팩터링 없이 비즈니스 로직 현대화 결과는 레거시 프로그램당 2~3개의 패키지로 구성됩니다.
가장 포괄적인 케이스는 세 가지 패키지로 구성됩니다.
-
base package.program.service에는 Program Process라는 인터페이스가 포함되어 있습니다. 여기에는 기존 실행 제어 흐름을 유지하면서 비즈니스 로직을 처리하는 비즈니스 메서드가 포함되어 있습니다. -
base package.program.service.impl: ProcessImplProgram이라는 클래스를 포함합니다. 이 클래스는 앞에서 설명한 Process 인터페이스의 구현입니다. 여기에서 기존 명령문을 AWS 블루 에이지 프레임워크에 따라 자바 명령문으로 “번역”합니다.
-
base package.program.statemachine: 이 패키지가 항상 있는 것은 아닙니다. 이는 레거시 제어 흐름을 현대화할 때 스테이트 머신 접근 방식 (즉, Spring StateMachine 프레임워크사용) 을 사용하여 레거시 실행 흐름을 적절하게 처리해야 하는 경우에 필요합니다. 이 경우 상태 시스템 하위 패키지에는 다음과 같은 두 개의 클래스가 포함됩니다.
-
ProgramProcedureDivisionStateMachineController:StateMachineController(스테이트 머신의 실행을 제어하는 데 필요한 작업 정의) 및StateMachineRunner(스테이트 머신 실행에 필요한 작업 정의) 인터페이스를 구현하는 클래스를 확장하는 클래스로, 예를 들어 샘플 사례의SimpleStateMachineController와 같이 Spring 스테이트 머신 메카닉을 구동하는 데 사용됩니다.
스테이트 머신 컨트롤러는 가능한 다양한 상태와 상태 간의 전환을 정의하여 주어진 프로그램에 대한 기존 실행 제어 흐름을 재현합니다.
상태 머신을 빌드할 때 컨트롤러는 상태 머신 패키지에 있는 관련 서비스 클래스에 정의되고 아래에 설명된 메서드를 참조합니다.
subConfigurer.state(States._0000_MAIN, buildAction(() -> {stateProcess._0000Main(lctx, ctrl);}), null); subConfigurer.state(States.ABEND_ROUTINE, buildAction(() -> {stateProcess.abendRoutine(lctx, ctrl);}), null); -
ProgramProcedureDivisionStateMachineService: 이 서비스 클래스는 앞에서 설명한 것처럼 상태 시스템 컨트롤러가 생성하는 상태 머신에 바인딩되는 데 필요한 몇 가지 비즈니스 로직을 나타냅니다.이 클래스의 메서드에 있는 코드는 스테이트 머신 컨트롤러에 정의된 이벤트를 사용합니다.
또한 상태 시스템 서비스는 앞에서 설명한 프로세스 서비스 구현을 직접적으로 호출합니다.
-
또한 base package.program 이름이 지정된 패키지는 프로그램당 하나의 클래스를 수집하여 프로그램 진입점 역할을 하므로 중요한 역할을 합니다(자세한 내용은 나중에 설명 참조). 각 클래스는 프로그램 진입점을 나타내는 표시인 Program 인터페이스를 구현합니다.
기타 아티팩트
-
BMSMAPs컴패니언
프로그램 관련 아티팩트 외에도 서비스 프로젝트에는 다양한 용도의 다른 아티팩트가 포함될 수 있습니다. CICS온라인 애플리케이션을 현대화하는 경우 현대화 프로세스는 json 파일을 생성하여 /src/main/resources 폴더의 map 폴더에 저장합니다.
Blu Age 런타임은 이러한 json 파일을 사용하여 SEND MAP 명령문에서 사용하는 레코드를 화면 필드에 바인딩합니다.
-
Groovy 스크립트
레거시 애플리케이션에 JCL 스크립트가 있었다면, 이러한 스크립트는 /src/main/resources/scripts 폴더에 저장되어 있는 멋진
스크립트로 현대화되었습니다 (자세한 내용은 나중에 설명). 
이러한 스크립트는 일괄 작업(전용, 비대화형, CPU 집약적 데이터 처리 워크로드)을 시작하는 데 사용됩니다.
-
SQL파일
기존 응용 프로그램에서 SQL 쿼리를 사용하는 경우 해당 현대화된 SQL 쿼리가 이름 지정 패턴 프로그램인 .sql을 사용하여 전용 속성 파일에 수집되었습니다. 여기서 프로그램은 해당 쿼리를 사용하는 프로그램의 이름입니다.
이러한 sql 파일의 내용은 현대화된 프로그램이 지정된 쿼리를 실행하는 데 사용하는(키=쿼리) 항목의 모음으로, 각 쿼리는 고유한 키와 연결됩니다.
예를 들어, COSGN 00C 프로그램은 "COSGN00C_1" (sql 파일의 첫 번째 항목) 키를 사용하여 쿼리를 실행하고 있습니다.
유틸리티 프로젝트 컨텐츠
이름이 “-tools”로 끝나는 유틸리티 프로젝트에는 다른 모든 프로젝트에서 사용할 수 있는 기술 유틸리티 세트가 포함되어 있습니다.
웹 프로젝트 콘텐츠
웹 프로젝트는 레거시 UI 요소를 현대화할 때만 존재합니다. 현대화된 애플리케이션 프론트엔드를 구축하는 데 사용되는 최신 UI 요소는 Angular
웹 프로젝트는 애플리케이션의 프런트 엔드 측면만 관리합니다. 유틸리티 및 엔티티 프로젝트에 의존하는 서비스 프로젝트는 백엔드 서비스를 제공합니다. 프런트 엔드와 백엔드 간의 연결은 표준 Blu Age 런타임 배포판의 일부인 Gapwalk-Application이라는 웹 애플리케이션을 통해 이루어집니다. AWS
프로그램 실행 및 직접적으로 호출
레거시 시스템에서 프로그램은 명령문과 같은 CALL 메커니즘을 통해 스스로 호출하고 필요할 때 인수를 전달할 수 있는 독립형 실행 파일로 컴파일됩니다. COBOL CALL 관련 아티팩트의 특성이 기존 애플리케이션과 다르기 때문에 현대화된 애플리케이션은 동일한 기능을 제공하지만 다른 접근 방식을 사용합니다.
현대화된 측면에서 보면 프로그램 진입점은 Program 인터페이스를 구현하는 특정 클래스이고 Spring 구성 요소(@Component)이며 서비스 프로젝트의 base package.program 이름이 지정된 패키지에 있습니다.
프로그램 등록
현대화된 애플리케이션을 호스팅하는 TomcatProgramRegistry라는 이름의 전용 레지스트리는 프로그램 항목으로 채워지며, 각 프로그램은 알려진 프로그램 식별자당 하나의 항목으로 식별자를 사용하여 등록됩니다. 즉, 프로그램이 여러 다른 식별자로 알려진 경우 레지스트리에는 식별자 수만큼의 항목이 포함됩니다.
지정된 프로그램의 등록은 () 메서드가 반환한 식별자 컬렉션을 기반으로 합니다. getProgramIdentifiers
이 예시에서는 프로그램이 CBACT '04C'라는 이름으로 한 번 등록됩니다 (컬렉션 내용 참조). programIdentifiers Tomecat 로그에는 모든 프로그램 등록이 표시됩니다. 프로그램 등록은 선언된 프로그램 식별자에만 의존하고 프로그램 클래스 이름 자체에는 의존하지 않습니다. 하지만 일반적으로 프로그램 식별자와 프로그램 클래스 이름은 정렬됩니다.
Blu Age 런타임 배포판의 일부인 다양한 유틸리티 AWS Blu Age 웹 애플리케이션에서 가져온 유틸리티 프로그램에도 동일한 등록 메커니즘이 AWS 적용됩니다. 예를 들어 Gapwalk-Utility-Pgm 웹앱은 z/OS 시스템 유틸리티 (IDCAMS,ICEGENER, SORT 등) 와 동일한 기능을 제공하며 현대화된 프로그램이나 스크립트로 호출할 수 있습니다. Tomcat 시작 시 등록된 사용 가능한 모든 유틸리티 프로그램은 Tomcat 로그에 기록됩니다.
스크립트 및 데몬 등록
Tomcat 시작 시 /src/main/resources/scripts 폴더 계층 구조에 있는 멋진 스크립트에 대해서도 비슷한 등록 프로세스가 발생합니다. 스크립트 폴더 계층 구조를 탐색하고 검색된 모든 groovy 스크립트(특수 함수.groovy 예약 스크립트 제외)는 짧은 이름(스크립트 파일 이름 중 첫 번째 점 문자 앞에 있는 부분)을 검색 키로 사용하여 ScriptRegistry에 등록됩니다.
참고
-
여러 스크립트에 동일한 등록 키를 생성하는 파일 이름이 있는 경우 최신 스크립트만 등록되어 해당 키에 대해 이전에 발생한 등록을 덮어씁니다.
-
위의 내용을 고려해 볼 때, 등록 메커니즘으로 인해 계층 구조가 단순해지고 예기치 않은 덮어쓰기가 발생할 수 있으므로 하위 폴더를 사용할 때는 주의해야 합니다. 등록 프로세스에는 계층 구조가 포함되지 않습니다. 일반적으로 /scripts/A/myscript.groovy와 /scripts/B/myscript.groovy는 /scripts/A/myscript.groovy를 덮어쓰게 되면 /scripts/B/myscript.groovy를 덮어씁니다.
/src/main/resources/daemons 폴더에 있는 멋진 스크립트는 약간 다르게 처리됩니다. 여전히 일반 스크립트로 등록되어 있지만, Tomcat 시작 시 바로 비동기적으로 한 번 실행됩니다.
스크립트가 에 등록되면 Gapwalk-Application에서 제공하는 전용 엔드포인트를 사용하여 호출을 통해 스크립트를 ScriptRegistry 시작할 수 REST 있습니다. 자세한 내용을 알아보려면 해당 문서를 참조하세요.
프로그램 직접적 호출 프로그램
각 프로그램은 다른 프로그램을 하위 프로그램으로 직접 호출하여 파라미터를 전달할 수 있습니다. 프로그램은 ExecutionController 인터페이스 구현 (대부분의 경우 이 ExecutionControllerImpl 인스턴스가 됨) 을 사용하고, 프로그램 호출 인수를 작성하기 위해 라는 이름의 유창한 API 메커니즘과 함께 인터페이스의 CallBuilder 구현을 사용합니다.
모든 프로그램 메서드는 RuntimeContext 및 ExecutionController를 메서드 인수로 모두 사용하므로 ExecutionController를 항상 사용하여 다른 프로그램을 직접적으로 호출할 수 있습니다.
예를 들어, CBST 03A 프로그램이 CBST 03B 프로그램을 하위 프로그램으로 호출하여 매개 변수를 전달하는 방법을 보여주는 다음 다이어그램을 참조하십시오.
-
ExecutionController.callSubProgram의 첫 번째 인수는 직접적으로 호출할 프로그램의 식별자입니다. 즉, 프로그램 등록에 사용되는 식별자 중 하나입니다. 위 단락 참조). -
CallBuilder를 기반으로 빌드한 결과인 두 번째 인수는 직접적으로 호출자에서 수신자에게 전달된 데이터에 해당하는Record의 배열입니다. -
세 번째이자 마지막 인수는 직접적 호출자
RuntimeContext인스턴스입니다.
세 인수는 모두 필수이며 null이 될 수 없지만 두 번째 인수는 빈 배열일 수 있습니다.
피호출자는 원래 그렇게 하도록 설계된 경우에만 전달된 파라미터를 처리할 수 있습니다. 레거시 COBOL 프로그램의 경우 요소를 USING 활용할 수 있도록 프로시저 분할을 위한 LINKAGE 섹션과 조항이 있어야 합니다. LINKAGE
예를 들어, 해당 CBSTM03B를 참조하십시오. CBL
따라서 CBSTM 03B 프로그램은 단일 Record 값을 매개 변수로 사용합니다 (크기 1의 배열). 이것은 byReference () 및 getArguments () 메서드 체인을 사용하여 빌드하고 있는 것입니다. CallBuilder
CallBuilderFluent API 클래스에는 피호출자에게 전달할 인수 배열을 채우는 데 사용할 수 있는 여러 메서드가 있습니다.
-
asPointer(RecordAdaptable): 참조로 포인터 종류의 인수를 추가합니다. 포인터는 대상 데이터 구조의 주소를 나타냅니다.
-
byReference(RecordAdaptable): 참조로 인수를 추가합니다. 호출자는 피호출자가 수행한 수정 내용을 볼 수 있습니다.
-
byReference(RecordAdaptable): 이전 메서드의 varargs 변형입니다.
-
byValue(객체):
Recorda로 변환된 인수를 값별로 추가합니다. 호출자는 피호출자가 수행한 수정 내용을 볼 수 없습니다. -
byValue(RecordAdaptable): 이전 메서드와 동일하지만 인수는 a로 직접 사용할 수
RecordAdaptable있습니다. -
byValueWith경계 (Object, int, int):
Recorda로 변환된 인수를 추가하고 주어진 경계로 정의된 바이트 배열 부분을 값별로 추출합니다.
마지막으로 getArguments 메서드는 추가된 모든 인수를 수집하여 의 배열로 반환합니다. Record
참고
인수 배열에 필요한 크기가 맞는지, 항목이 적절하게 정렬되고, 메모리 레이아웃이 연결 요소에 대한 예상 레이아웃과 호환되는지 확인하는 것은 직접적으로 호출자의 책임입니다.
프로그램을 직접적으로 호출하는 스크립트
groovy 스크립트에서 등록된 프로그램을 직접적으로 호출하려면 MainProgramRunner 인터페이스를 구현하는 클래스 인스턴스를 사용해야 합니다. 일반적으로 이러한 인스턴스는 Spring ApplicationContext 사용을 통해 얻을 수 있습니다.
MainProgramRunner인터페이스를 사용할 수 있게 되면 runProgram 메서드를 사용하여 프로그램을 호출하고 대상 프로그램의 식별자를 매개 변수로 전달합니다.
이전 예제에서는 작업 단계가 IDCAMS (파일 처리 유틸리티 프로그램) 을 호출하여 실제 데이터 세트 정의와 해당 논리적 식별자 간의 매핑을 제공합니다.
데이터 세트를 처리할 때 기존 프로그램은 대부분 논리적 이름을 사용하여 데이터 세트를 식별합니다. 스크립트에서 프로그램을 직접적으로 호출할 때 스크립트는 논리적 이름을 실제 물리적 데이터 세트와 매핑해야 합니다. 이러한 데이터 세트는 파일 시스템, Blusam 스토리지에 있을 수도 있고 인라인 스트림, 여러 데이터 세트의 연결 또는 생성을 통해 정의될 수도 있습니다. GDG
withFileConfiguration 메서드를 사용하여 데이터 세트의 논리적-물리적 맵을 작성하고 호출된 프로그램에서 사용할 수 있도록 합니다.
직접 프로그램을 작성하세요
스크립트나 기타 현대화된 프로그램을 직접적으로 호출할 프로그램을 직접 작성하는 것은 일반적인 작업입니다. 일반적으로 현대화 프로젝트에서는 실행 가능한 레거시 프로그램이 현대화 프로세스에서 지원하지 않는 언어로 작성되었거나 소스가 손실된 경우(예, 그럴 수 있음) 또는 프로그램이 소스를 사용할 수 없는 유틸리티인 경우 프로그램을 직접 작성합니다.
이 경우 누락된 프로그램을 Java로 직접 작성해야 할 수도 있습니다(프로그램 예상 동작이 무엇인지, 프로그램 인수의 메모리 레이아웃(있는 경우) 등에 대해 충분히 알고 있다고 가정하면 됩니다 Java 프로그램은 이 문서에 설명된 프로그램 메커니즘을 준수해야 다른 프로그램과 스크립트에서 실행할 수 있습니다.
프로그램을 사용할 수 있게 하려면 다음 두 가지 필수 단계를 완료해야 합니다.
-
등록 및 직접적 호출이 가능하도록
Program인터페이스를 제대로 구현하는 클래스를 작성하세요. -
다른 프로그램/스크립트에서도 볼 수 있도록 프로그램이 제대로 등록되었는지 확인하세요.
프로그램 구현 작성
를 IDE 사용하여 Program 인터페이스를 구현하는 새 Java 클래스를 만드십시오.
다음 이미지는 구현해야 할 모든 필수 메서드를 생성하는 IDE Eclipse를 보여줍니다.
Spring 통합
먼저 클래스를 Spring 컴포넌트로 선언해야 합니다. 클래스에 @Component 주석을 달아주세요.
다음으로 필요한 메서드를 제대로 구현하세요. 이 샘플의 맥락에서 현대화된 모든 프로그램이 이미 들어 있는 패키지에 MyUtilityProgram를 추가했습니다. 이 배치를 통해 프로그램은 기존 Springboot 애플리케이션을 사용하여 메서드 ConfigurableApplicationContext 구현에 필요한 것을 제공할 수 있습니다. getSpringApplication
자체 프로그램을 위해 다른 위치를 선택할 수도 있습니다. 예를 들어, 특정 프로그램을 다른 전담 서비스 프로젝트에서 찾을 수 있습니다. 주어진 서비스 프로젝트에 자체 Springboot 애플리케이션이 있는지 확인하세요. 그러면 ApplicationContext (a여야 ConfigurableApplicationContext 함) 을 검색할 수 있습니다.
프로그램에 ID 부여
다른 프로그램 및 스크립트에서 직접적으로 호출할 수 있으려면 프로그램에 하나 이상의 식별자를 지정해야 합니다. 식별자는 시스템 내에 등록된 다른 기존 프로그램과 충돌하지 않아야 합니다. 기존 레거시 프로그램을 대체해야 하기 때문에 식별자를 선택해야 할 수도 있습니다. 이 경우 레거시 프로그램 전반에 걸쳐 발견된 예상 식별자를 사용해야 합니다. CALL 레거시 시스템에서는 대부분의 프로그램 식별자 길이가 8자입니다.
프로그램에서 수정할 수 없는 식별자 세트를 만드는 것도 이 작업을 수행하는 한 가지 방법입니다. 다음 예에서는 MYUTILPG "“를 단일 식별자로 선택하는 방법을 보여 줍니다.
프로그램을 컨텍스트에 연결
프로그램에는 컴패니언 RuntimeContext 인스턴스가 필요합니다. 현대화된 프로그램의 경우 AWS Blu Age는 레거시 프로그램의 일부인 데이터 구조를 사용하여 컴패니언 컨텍스트를 자동으로 생성합니다.
프로그램을 직접 작성하는 경우 컴패니언 컨텍스트도 작성해야 합니다.
프로그램 관련 클래스를 참조하면 프로그램에는 최소한 두 개의 컴패니언 클래스가 필요하다는 것을 알 수 있습니다.
-
새 구성 클래스.
-
구성을 사용하는 컨텍스트 클래스.
유틸리티 프로그램에서 추가 데이터 구조를 사용하는 경우 해당 데이터 구조도 작성하여 컨텍스트에서 사용해야 합니다.
이러한 클래스는 Spring 프레임워크에서 컨텍스트 구성 요소 및 구성을 처리하도록 하려면 응용 프로그램 시작 시 스캔되는 패키지 계층 구조의 일부인 패키지에 있어야 합니다.
엔티티 프로젝트에서 새로 만든 base package.myutilityprogram.business.context 패키지에 최소한의 구성과 컨텍스트를 작성해 보겠습니다.
다음은 구성 내용입니다. 인근의 현대화된 다른 프로그램과 유사한 구성 빌드를 사용하고 있습니다. 특정 요구 사항에 맞게 이를 사용자 정의해야 할 수도 있습니다.
참고:
-
일반적인 명명 규칙은 ProgramName구성입니다.
-
@org.springframework.context.annotation.Configuration 및 @Lazy 주석을 사용해야 합니다.
-
콩 이름은 일반적으로 ProgramNameContextConfiguration 규칙을 따르지만 필수 사항은 아닙니다. 프로젝트 전체에서 빈 이름이 충돌하지 않도록 하세요.
-
구현할 단일 메서드는
Configuration객체를 반환해야 합니다.ConfigurationBuilder유창한 언어를 API 사용해서 만들어 보세요.
그리고 관련 컨텍스트:
참고
-
컨텍스트 클래스는 기존
Context인터페이스 구현 (RuntimeContext또는JicsRuntimeContext, JICS 특정 항목이 추가되어 개선됨)RuntimeContext을 확장해야 합니다. -
일반적인 명명 규칙은 컨텍스트입니다. ProgramName
-
프로토타입 구성 요소로 선언하고 @Lazy 주석을 사용해야 합니다.
-
생성자는 @Qualifier 주석을 사용하여 적절한 구성 클래스를 대상으로 하는 관련 구성을 참조합니다.
-
유틸리티 프로그램에서 몇 가지 추가 데이터 구조를 사용하는 경우 다음과 같아야 합니다.
-
작성되어
base package.business.model패키지에 추가되었습니다. -
컨텍스트에서 참조되었습니다. 기존의 다른 컨텍스트 클래스를 살펴보고 필요에 따라 데이터 구조 클래스를 참조하고 컨텍스트 메서드(생성자/정리/재설정) 를 조정하는 방법을 살펴보세요.
-
이제 전용 컨텍스트를 사용할 수 있으므로 새 프로그램에서 해당 컨텍스트를 사용하도록 해 보겠습니다.
참고:
-
getContext 메서드는
ProgramContextStore클래스의 getOrCreate 메서드에 대한 위임과 자동 연결BeanFactorySpring을 사용하여 그림과 같이 엄격하게 구현되어야 합니다.ProgramContextStore에 프로그램 컨텍스트를 저장하는 데 단일 프로그램 식별자가 사용됩니다. 이 식별자를 '프로그램 기본 식별자'라고 합니다. -
동반 구성 및 컨텍스트 클래스는
@Import스프링 주석을 사용하여 참조해야 합니다.
비즈니스 로직 구현
프로그램 스켈레톤이 완료되면 새 유틸리티 프로그램에 대한 비즈니스 로직을 구현하세요.
프로그램의 run 메서드로 이 작업을 수행하세요. 이 메서드는 다른 프로그램이나 스크립트에서 프로그램을 호출할 때마다 실행됩니다.
즐거운 코딩 되세요!
프로그램 등록 처리
마지막으로 새 프로그램이 ProgramRegistry에 제대로 등록되었는지 확인하세요. 이미 다른 프로그램이 들어 있는 패키지에 새 프로그램을 추가한 경우에는 더 이상 할 일이 없습니다. 응용 프로그램 시작 시 새 프로그램이 선택되어 모든 인접 프로그램에 등록됩니다.
다른 프로그램 위치를 선택한 경우 Tomcat 시작 시 프로그램이 제대로 등록되었는지 확인해야 합니다. 이를 수행하는 방법에 대한 영감을 얻으려면 서비스 프로젝트에서 생성된 SpringbootLauncher 클래스의 initialize 메서드를 살펴보세요 (참조서비스 프로젝트 내용).
Tomecat 시작 로그를 확인하세요. 모든 프로그램 등록이 기록됩니다. 프로그램이 성공적으로 등록되면 일치하는 로그 항목을 찾을 수 있습니다.
프로그램이 제대로 등록되었는지 확인되면 비즈니스 로직 코딩에 대한 반복 작업을 시작할 수 있습니다.
완전한 이름 매핑
이 섹션에는 AWS Blu Age 목록과 현대화된 애플리케이션에서 사용할 수 있는 타사의 정식 이름 매핑 목록이 수록되어 있습니다.
AWS Blu Age 정식 이름 매핑
| 짧은 이름 | 정규화된 인덱스 이름 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
타사의 완전한 자격을 갖춘 이름 매핑
| 짧은 이름 | 정규화된 인덱스 이름 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
