[I] Flow

• [C] SimpleFlow
  • [C] JsrFlow

Flow
Batch의 Flow 도메인 클래스이며, 순차 Step 실행에는 Flow가 관여하지 않지만, on 과 같은 더 복잡한 흐름 제어가 필요한 경우 Flow가 필요

• 메소드
  • FlowExecution start(FlowExecutor) : Flow의 실행을 담당하는 메소드
  • FlowExecution resume(stateName, FlowExecutor) : 특정 State 부터 다시 실행하게 하는 메소드
  • Collection<State> getStates() : Flow에 속한 State를 모두 리턴하는 메소드, State는 handle 메소드를 가지며, FlowExeStatus를 리턴

SimpleFlow
종료의 상태는 마지막 State에 의존

• 변수
  • startState : 시작점 State
  • transitionMap : StateTransition의 Map, Transition을 통해 다음 어떤것을 수행할지 나타낼수 있음
  • StateMap : State에 대한 Map
  • stateTransitions : Transition의 리스트
  • stateTransitionComparator : Transition 비교를 위한 클래스
• 메소드
  • FlowExecution start(FlowExecutor) : 첫번째 Step부터 실행(resume 호출)
  • FlowExecution resume(stateName, FlowExecutor) : isFlowContinued를 반복해서 호출하며 State를 실행
  • isFlowContinued(State, FlowStatus, StepExe) : State의 상태를 판단하여, Flow를 더 실행할지 제어하는 메소드
  • nextState(stateName, FlowStatus, StepExe) : 다음 State를 구하는 메소드

JsrFlow
JSR-352의 로직을 구현한 Flow

[I] Step

• [C] AbstractStep
  • [C] PartitionStep
    • [C] PartitionStep
  • [C] TaskletStep
    • [C] BatchletStep
  • [C] DecisionStep
  • [C] JobStep
  • [C] FlowStep

Step
Step 설정을 나타내는 배치 도메인 인터페이스

• 메소드
  • isAllowStartIfComplete : Complete 더라도 재실행을 허용할지
  • getStartLimit : 동일 식별자로 실행될수 있는 횟수
  • execute(StepExecution) : Step 의 처리를 다루는 메소드

AbstractStep
Step에 공통처리로직을 담은 AbstractClass

• 변수
  • CompositeStepExecutionListener : StepExecutionListener를 컴포지트로 가지고 있으며 Step의 선 후 단계에서 호출하는 컴포지트 리스너
  • JobRepository : Job의 메타 정보들을 담당
• 메소드
  • open(ExecutionContext) : doExecute(stepExe)를 호출하기 전 호출
  • close(ExecutionContext) : doExecute(stepExe) 이후 finally에서 호출
  • [A] doExecute() : 실제 Step 실행을 위해 열어놓은 메소드
  • [A] doExecutionRelease() : doExecute(stepExe) 이후 finally에서 close이후 호출
  • [final] execute(StepExe) : Step에 실행을 다루는 메소드, open, close 및 doExecute()를 실행

PartitionStep
Partition 처리를 위한 Step, 결국 파티셔너를 통해 StepExecutio을 여러개로 만들어서 Executor를 통해 수행
Executor가 기본적으로는 Sync지만, 변경하면 parallel도 가능

• 변수
  • StepExecutionSplitter : Step을 Split하는 전략을 다루는 클래스, Set split(StepExe, gridSize)
  • PartitionHandler : Collection handle(StepExecutionSplitter,StepExe)
  • StepExecutionAggregator : Aggregate의 전략을 다루는 클래스 aggregate(StepExe, Collection)
• 메소드
  • doExecute() : TaskExecutorPartitionerHandler 기준으로, executor.execute(task)로 다 돌린 후, stepExeAggregator.aggregate를 통해 aggregate

TaskletStep
간단 실행을 위한 Tasklet을 다루는 TaskletStep, 반복이 가능하며, 각 호출 마다 트랜잭션으로 묶인다.

• 변수

  • RepeatOperations : Step에 반복 여부를 처리하는 Operations
  • CompositeChunkListener : ChunkListener 들을 컴포지트로 가지고 있는 Listener, chunk 전후에 호출
  • StepInterruptionPolicy : step 호출시마다 종료되었는지를 체크하는 클래스
  • CompositeItemStream : ItemStream을 컴포지트로 가지고있는 클래스, Overide 한 open, close, AbstractStep에 execute()에서
  • PlatformTransactionManager : Step처리에 트랜잭션 제어를 위한 트랜잭션 매니져
  • TransactionAttribute : 에러시 롤백 할지 등의 전략을 제공하는 Attribute

• 메소드

  • doExecute() : TaskExecutorPartitionerHandler 기준으로, executor.execute(task)로 다 돌린 후, stepExeAggregator.aggregate를 통해 aggregate

DecisionStep
JSR-352에 정의되어있는 DecisionStep이며, JSR-352에 있는것 모두 지원하는 것은 아님

• 변수

  • Decider : 종료 상태를 결정, String decide(StepExe[])

JobStep
Job을 실행할 수 있도록 하는 Step, 파티셔닝 실행 및 병렬 실행 지원

• 변수

  • Job : 호출할 Job
  • JobLauncher : Job 실행을 위한 Launcher
  • JobParametersExtractor : JobParam getJobParameters(Job, StepExe) 을 통해 JobParam을 구하는 클래스

• 메소드

  • doExecute() : jobParam 생성, JobLauncher를 통해 job 실행

FlowStep
Flow 실행을 위한 Step
Step의 그룹핑 실행과 여러 Step들의 파티셔닝 등을 위한 Step
(FlowJob과 거의 코드가 비슷..)

• 변수

  • Flow : 실행할 Flow

• 메소드

  • doExecute() : FlowExecutor를 통한 Flow 실행

추후 State, Execution

다시 Spring Batch를 분석해야할 필요성이 생겨서....
어떤 클래스 구조들을 가지고, 어떤 기능들 및 구현범위들을 제공하고 있는지 살펴보고 있습니다.
물론 일반 개발자들이 Job을 손대거나 커스터마이징 할 일은 잘 없겠지만..

• [I] Job
  • [C] GroupAwareJob
  • [AC] AbstractJob
    • [C] SimpleJob
    • [C] FlowJob
      • [C] JsrFlowJob

Job
배치에서 Job을 표현하는 가장 상위 도메인 인터페이스, 재시작은 Step 단위가 아니라 Job 단위임을 isRestartable()을 통해 알수 있음

• getJobParametersValidator() : JobParameter 값의 유효성 체크
• getJobParametersIncrementer() : Job 실행시 새로운 파라미터를 만들경우(JobParametersIncrementer에 구현 내용은 실제로 JobParam을 받아 JobParam을 리턴하도록 되어있음)
• isRestartable() : 재시작 여부

GroupAwareJob
배치명을 그룹명을 포함하여 활용할 경우, 발췌잡 -> 론뱅크.발췌잡
그룹명을 들고 있고, 메소드는 다 Job에 있는 것들을 delegate 하여 호출하는 방식

AbstractJob
추상 클래스이며, 공통 의존성들에 대해(JobRepository나 JobExecututionListener나..) 설정들에 대해 로직들이 기술되어있음
실제 대부분 모든 Job은 AbstractJob을 상속받아 구현한 구현체일것
Step 관련된 로직은 대부분 Abstract로 두어 구현한 Job에 따라 원하는 형태로 관리할 수 있도록 함

• 변수
  • JobRepository : Job의 정보(Param 이나 메타정보)들을 얻거나, 상태를 업데이트 하는 repo
  • CompositeJobExecutionListener : Job 선후에 불릴 JobExecutionListener들을 등록받아 일괄로 불러주는 컴포지트 클래스
  • StepHandler : step의 실제 처리 로직(실행 및 재처리에 따른 처리 및 상태처리 등)을 담고 있는 핸들러
• 메소드
  • [A] getStep(String) : 추상메소드로 둬서 Step을 어떻게 저장하고 관리할지는 위로 위임
  • [A] getStepNames() : 추상메소드로 둬서 Step을 어떻게 저장하고 관리할지는 위로 위임
  • [final] execute(JobExe) : Job의 메소드이며 핸들러 호출 및 Repo 호출 등에 대한 로직이 담겨 있음, final로 구현 내용을 바꾸지 못하도록 했고, 메소드에서는 doExecute()을 호출하도록 되어있기 때문에 구현 클래스에서는 Job실행은 doExecute()을 통해 구현
  • [final] handleStep(Step, JobExe) : step에 실행에 대한 메소드를 final로 내용을 변경하지 못하도록 했고, StepHandler를 변경함으로 내용을 변경할 수 있도록 제공
  • [A] doExecute(JobExe) : 구현 클래스에서 Job 실행 부분을 구현하도록 열어놓은 메소드

SimpleJob
Step을 순차적으로 실행하는 Job의 구현체
Step이 실패시 Job이 실패하며, 모든 Step이 Complete 될경우 Job이 Complete 된다.

• 변수
  • ArrayList : Step을 ArrayList로 관리//Step이 그렇게 많지는 않겠지만, getStep은 O(n)
• 메소드
  • doExecute(JobExe) : step을 handleStep()으로 호출, Completed가 아닐시 break

FlowJob
순차실행 보다는 Flow를 통한 복잡한 처리를 위한 JobClass
초기 작업에서(findSteps) Flow에 있는 Step들을 stepMap에 넣고 시작

• 변수
  • Flow : 실행할 Flow, 내부에 여러 Step이 존재
  • Map<String,Step> : Flow내에 존재하는 Step을 파싱(findSteps())하여 저장
• 메소드
  • findSteps(Flow,Map) : Flow에서 Step들의 정보들을 꺼내서 Map에 저장
  • doExecute(JobExe) : flow.start(FlowExecutor)

JsrFlowJob
FlowJob을 상속 JSR-352 명세에 FlowJob

요즘 약국의 공공마스크 재고를 확인하는 API 를통해

많이들 만드시는 "공공마스크 재고" 페이지를 만들어봤습니다.

https://meteorkor.github.io/maskMap/

사실 퀄리티 좋은 맵들이 많아서 사실 불필요할 수 있지만

개인적으로 Map Api들도 활용해본적이 없기 때문에

추후 Map Api를 한번 사용해봐야지 했던터라

불필요할것 같지만 안해보기는 아쉬울것 같아 만들어 보았습니다.

(다음맵 선택 가능하지만, 대부분 다음Map을 사용하신것 같아 네이버맵 으로 만들어봤습니다.)

현재 토이 프로젝트를 목적으로 라즈베리파이 서버를 사용하고 있지만

"공공마스크 재고"를 위해서는 굳이 백엔드가 필요하지 않을것 같아

사실 html 페이지 하나만을 위해 웹서버를 띄우기는 조금 낭비 같아서

github page를 사용해서 html페이지를 띄웠고

덕분에 도메인도 자동으로 github.io을 달고 공개할 수 있었습니다.

생각날때 마다 조금씩 수정하고 있는데

당연한 내용이지만 하나씩 수정 내용을 남기려고 합니다.

1. 조회 API 호출은 "bounds_changed" 이벤트가 호출시

2. "bounds_changed" 마다 부르니 너무 API가 많이 불리니, API 호출시에는 "bounds_changed"가 불리더라도 API를 호출하지않도록 수정

3. 움직여서 API를 호출하더라도 marker를 중복으로 그리는 현상이 있으니, 중복 체크해서 그리지 않도록

4. API의 주어진 검색범위는 5km인데, 3km 로 고정 제공하다 zoom 정도에 따라 검색 범위를 수정하도록

5. zoom controller 를 화면에 추가

6. "bounds_changed"는 zoom만 변경되더라도 호출되고, 드래그를 하는 중에도 호출되기 때문에 "dragend" 이벤트로 변경

코드는 오픈되어있습니다.

물론.. 다듬어야 할 부분은 상당히 많습니다..^^;

https://github.com/Meteorkor/maskMap

블로그를 github.io를 검토하며 처음 보는 Jekyll 이라는게 있어서

github.io 즉 github페이지를 이루는 엔진이 Jekyll인지

테마만 지원해주는게 Jekyll인지 

Jekyll의 정체를 몰라서 검색을 해본 결과를 남깁니다.

Jejkyll은 "static site generator built-in support for GitHub Pages" 라는 말이 적혀있었습니다.

즉 사람들이 마크다운이나 각종 설정들을 통해 작성한 내용을

바로 웹서비스 할 수 있도록 정적 페이지를 만들어주는 모듈? 정도로 이해하면 될것 같습니다.

(결국 마크다운이나 그 설정들을 통해 깃헙 페이지 서비스에서만 활용하는게 아니라 Jekyll로 정적 페이지들을 뽑아내서 다른 웹서버로 서비스도 가능할것으로 보입니다.)

출처 : 

https://help.github.com/en/github/working-with-github-pages/about-github-pages-and-jekyll

https://jekyllrb.com/