백엔드의 고전적인 경우와 마찬가지로 AppMaster 애플리케이션의 백엔드에 있는 작업 스케줄러는 반복되는 시나리오를 생성합니다. 예를 들어 일정에 따라 특정 작업을 수행해야 하는 경우입니다. 이러한 작업의 전형적인 예는 서버의 임시 파일 정리, 주간 백업, 주어진 알고리즘에 따른 보고서 생성 등입니다.
AppMaster 애플리케이션 백엔드에서 작업 스케줄러를 사용하는 예를 살펴보겠습니다. 매일 아침 오전 9시에 사용자에게 휴대폰 번호로 날씨를 전송하는 프로세스를 구축한다고 가정합니다.
따라서 작업은 여러 논리적 단계로 나뉩니다.
- 모바일 메시지 전송을 위한 모듈 설치 및 구성
- 외부 요청 API 프로세스 생성 및 구성
- 애플리케이션 백엔드에서 스케줄러 설정
1. 모바일 메시지 전송을 위한 모듈 설치 및 구성. Nexmo 모듈을 사용하면 선택한 번호로 SMS 메시지를 전송하는 기능을 AppMaster 애플리케이션에 통합할 수 있습니다.
- API 키 - Nexmo 계정( https://dashboard.nexmo.com/settings )에서 얻을 수 있는 API 키
- API 비밀 - 사용자를 식별하기 위해 API 키와 함께 사용되는 개인 키입니다. Nexmo 계정( https://dashboard.nexmo.com/settings )에서도 다운로드할 수 있습니다.
- 발신 번호 - Nexmo 계정에 등록할 때 지정한 번호입니다.
모듈 설치와 함께 다음 비즈니스 프로세스가 자동으로 설치됩니다.
- Nexmo.Send SMS - 지정된 번호로 메시지를 보낼 수 있습니다.
넥스모 모듈:
- 전화 [전화] - 메시지가 전송될 전화번호.
- 내용 [문자열] - 문자 메시지;
2. 무료 OpenWeather API 웹 리소스는 날씨 데이터 소스( https://openweathermap.org/api )로 사용됩니다. 첫 번째 단계는 외부 요청 API 템플릿을 만드는 것입니다. API 요청 템플릿은 외부 API 요청 탭의 비즈니스 프로세스 섹션에 표시됩니다. 새 템플릿을 생성하려면 API 요청 생성을 클릭합니다.
요청 유형: GET
요청 주소: https://api.openweathermap.org/data/2.5/weather
쿼리 매개변수:
- 위도 [문자열] - 위도
- Lon [문자열] - 경도
- Appid [문자열] - OpenWeather API 키
이 작업의 일부로 기본 응답 본문( https://openweathermap.org/api/one-call-3 )의 일부 필드에만 관심이 있습니다.
- 온도 [부동] - 온도
- Temp_min [float] - 최소 온도
- Temp_max [float] - 최대 온도
- 압력 [부동] - 압력
- 습도 [부유] - 습도
3. 작업 스케줄러를 설정하기 전에 API를 통해 날씨 정보를 수신할 비즈니스 프로세스를 생성해야 합니다. 비즈니스 프로세스는 다음과 같습니다.
- Make Weather Query Model In - 가상 요청 매개변수 모델을 생성합니다. Lon, lat - 원하는 위치의 좌표, appid - OpenWeather 서비스의 API 키.
- API 요청: 날씨 - OpenWeather API와 상호 작용하는 비즈니스 프로세스
- Expand Weather: Body Model Out - Body 응답 모델을 배포하는 데 필요
- Expand Weather: Body Model Out_main - 온도(temp)를 얻기 위해 요청-응답 바디의 메인 모델을 확장한다.
- To String - 임시 필드 값을 문자열 유형으로 변환합니다.
- Nexmo: SMS 보내기 - 지정된 전화번호(전화)로 온도(콘텐츠) 정보가 포함된 메시지를 보냅니다.
스케줄러 탭의 비즈니스 프로세스 섹션에서 스케줄러를 설정합니다.
스케줄 탭의 스케줄러 설정은 유형에 따라 다릅니다.
각각에 대해 자세히 살펴 보겠습니다.
1. 매일 - 일일 일정을 구성할 수 있습니다.
- 시간 - 스케줄러가 선택한 BP를 시작하는 시간(UTC+0)을 정의합니다.
- 요일 - 스케줄러가 작동할 요일을 정의합니다.
- 자동 시작 - True로 설정하면 이전 BP가 완료되지 않은 경우 새 BP가 시작되지 않습니다. 기본값: 거짓.
- 자동 재시도 - 프로세스가 중단되었거나 성공적으로 시작되지 않은 경우 자동으로 프로세스를 다시 시작합니다.
실패한 항목 처리 재시도 - 프로세스를 다시 시작하려는 시도 횟수.
각 재시도 전에 대기 - 프로세스를 다시 시작하기 위해 각 샷 전에 지연 시간;
- 강제 종료 - 몇 초 이내에 완료되지 않으면 프로세스를 강제로 종료합니다. 기본적으로 사실입니다. 완료될 때까지의 시간(초)은 기본적으로 3초입니다.
2. 월간 - 월간 플래너
- 시간 - 스케줄러가 선택한 BP를 시작하는 시간(UTC+0)을 정의합니다.
- 요일 - 두 가지 설정으로 구성됩니다.
반복 빈도:
- 모든 처음
- 매 초
- 3분의 1마다
- 4분의 1마다
- 이날
요일 - 요일을 정의합니다.
- 월 - 월이 결정됨
- 자동 시작 - True로 설정하면 곧 완료될 때까지 새 PSU가 시작되지 않습니다. 기본값: 거짓.
- 자동으로 재시도 - 프로세스가 중단되었거나 시작되지 않은 경우 자동으로 프로세스를 다시 시작합니다.
실패한 항목 처리 재시도 - 프로세스 재시작 횟수.
각 재시도 전 대기 - 프로세스를 다시 시작하기 위한 각 시도 전의 지연 시간.
- 강제 종료 - 몇 초 이내에 완료되지 않으면 프로세스를 종료합니다. 기본적으로 사실입니다. 완료될 때까지의 시간(초)은 기본적으로 3초입니다.
3. 주기적으로 - 스케줄러의 빈도를 유연하게 구성할 수 있습니다.
- Every - N초/분/시간/일마다 반복성을 설정하는 기능. 기본값: 1시간마다.
- 자동 시작 - True로 설정하면 이전 BP가 완료되지 않은 경우 새 BP가 시작되지 않습니다. 기본값: 거짓.
- 자동 재시도 - 프로세스가 중단되었거나 성공적으로 시작되지 않은 경우 자동으로 프로세스를 다시 시작합니다.
실패한 항목 처리 재시도 - 프로세스를 다시 시작하려는 시도 횟수.
각 재시도 전에 대기 - 프로세스를 다시 시작하기 위해 각 샷 전에 지연 시간;
- 강제 종료 - 몇 초 이내에 완료되지 않으면 프로세스를 강제로 종료합니다. 기본적으로 사실입니다. 완료될 때까지의 시간(초)은 기본적으로 3초입니다.
4. 앱 실행 후 - 일회성 작업 플래너
- 지연 - 응용 프로그램 시작과 시작 사이의 지연을 정의합니다. 기본값 - 0초
- 자동 재시도 - 프로세스가 중단되었거나 성공적으로 시작되지 않은 경우 자동으로 프로세스를 다시 시작합니다.
실패한 항목 처리 재시도 - 프로세스를 다시 시작하려는 시도 횟수.
각 재시도 전에 대기 - 프로세스를 다시 시작하기 위해 각 샷 전에 지연 시간;
- 강제 종료 - 몇 초 이내에 완료되지 않으면 프로세스를 강제로 종료합니다. 기본적으로 사실입니다. 완료될 때까지의 시간(초)은 기본적으로 3초입니다.
5. 앱 종료 전 - 앱이 종료될 때마다 스케줄러 실행
- 자동 재시도 - 프로세스가 중단되었거나 성공적으로 시작되지 않은 경우 자동으로 프로세스를 다시 시작합니다.
실패한 항목 처리 재시도 - 프로세스를 다시 시작하려는 시도 횟수.
각 재시도 전에 대기 - 프로세스를 다시 시작할 때마다 지연 시간.
- 강제 종료 - 몇 초 이내에 완료되지 않으면 프로세스를 강제 종료합니다. 기본적으로 사실입니다. 완료될 때까지의 시간(초)은 기본적으로 3초입니다.
스케줄러 설정의 매개변수 탭에서 스케줄러에 의해 실행될 때 BP 입력에 매개변수를 전달할 수도 있습니다.
이 예에서 스케줄러 설정은 다음과 같습니다.
- 메시지는 매일 오전 9시 UTC+0에 전송됩니다.
- 프로세스가 즉시 시작되지 않은 경우 시도 사이에 10분의 지연으로 프로세스를 3회 자동으로 다시 시도합니다.
- 3초 이내에 완료되지 않으면 프로세스를 강제 종료합니다.
우리 애플리케이션은 백엔드에서 작동하며 작동하므로 게시하는 것으로 충분합니다.
