Различные комбинации шагов весенней партии

Question

Я работаю над проектом, где я собираюсь использовать Spring Batch и Spring Integration для создания системы документооборота. Эта система документооборота должна иметь возможность читать сообщения из очередей, которые на самом деле являются запросами на работу от клиентов, и в зависимости от типа запросов на задание мне нужно вызывать некоторые 7-8 систем.

Каждая система считывает входные файлы из некоторого местоположения (обычно это централизованная система хранения, в которой все входные файлы хранятся как отправленные клиентами), обрабатывает ее, а затем передает ее следующей системе и в конечном итоге я могу дать ответ для клиентов, таких как SUCCESS, если он обрабатывается всеми системами успешно и FAILED, если какая-либо система не может обработать файл, и если это не удается, клиент должен иметь возможность перезапустить неудавшееся задание с шага, на котором он действительно не удалось.

Я собираюсь добавить каждую систему в качестве шага в Spring Batch, а затем использовать Spring Integration. Я собираюсь моделировать конкретный поток системы. FTP получает файлы, отправляет запрос JMS/SMAPI, получает ответ JMS, файлы FTP обратно. и т.д.

Мои вопросы:

1. Является ли это правильный подход?
2. Если «да», каковы требования к настройке производительности при использовании Spring Batch и Spring Integration?
3. Поскольку все системы не будут вызываться в одном и том же порядке все время, как написать все возможные комбинации с использованием Spring Batch в качестве потенциальных заданий Spring Batch?

Answer 1

Вопрос 1: Использование Spring-Integration и Spring-Batch вместе - хорошая идея.

Вопрос 2: С Spring-Batch у вас есть множество возможностей масштабирования и улучшения для повышения производительности. Вы можете запустить целую работу параллельно, вы можете выполнить шаги параллельно, вы можете выполнить Куски параллельно ... Основные вопросы:

1. Где узкое
2. Где параллелизм улучшает производительность

Вопрос 3: В принципе, Spring-Batch не является системой документооборота. Он поддерживает задания с фиксированным порядком шагов.

Вариант 1: Вы можете смоделировать каждую систему в своей собственной работе («jobSystemA», «jobSystemB»). При этом вы можете реализовать логику потока на своем «интеграционном» уровне и начать новое задание для каждой системы в правильном порядке.

Вариант 2: Если у вас есть фиксированное количество возможных потоков как

Flow 1: 
Step A (System A) 
Step B (System B) 
Step C (System C) 

Flow 2: 
Step A (System A) 
Step C (System C) 
Step B (System B) 

Вы могли бы определить задание для каждого возможного «Потока» и осуществить вызов конкретных рабочих мест системы, как «StepJob» который вызывает конкретную «jobSystem» -job, указанную в варианте 1; что-то вроде

JobFlow1 
    Step1 {JobStep call jobSystemA} 
    Step2 {JobStep call jobSystemB} 
    Step3 {JobStep call jobSystemC} 

JobFlow2 
    Step1 {JobStep call jobSystemA} 
    Step2 {JobStep call jobSystemC} 
    Step3 {JobStep call jobSystemB} 

Вариант 3: Если вы определяете работу программно с помощью текучего API из SpringBatch, вы можете создать таким образом, чтобы определить работу во время выполнения.