Многие пользователи Obsidian пишут пользовательские задания на Java и используют свою существующую кодовую базу для выполнения таких вещей, как архив файлов или передача файлов прямо внутри работы. Хотя замечательно использовать повторно имеющийся у вас код, иногда пользователи в конечном итоге реализуют одну и ту же логику в нескольких заданиях, что не является идеальным, поскольку это требует дополнительного контроля качества и потенциальных несоответствий и необработанных ошибок.
К счастью, настраиваемая поддержка цепочек в Obsidian в сочетании с использованием результатов заданий (т. Е. Вывода) позволяет разработчикам написать одно задание в качестве компонента многократного использования, а затем при необходимости связать его с цепочкой.
Чтобы продемонстрировать это, мы рассмотрим довольно распространенный тип ситуации, когда у вас есть задание, которое генерирует ноль или более файлов, которые должны быть переданы на удаленный FTP-сайт и которые также должны быть заархивированы. Мы могли бы соединиться с заданием FTP, которое связывается с заданием архивирования, но для упрощения этого примера мы свяжем их в одно задание.
Задание создания файла
Сначала мы продемонстрируем, как сохранить результаты работы в нашей исходной работе, чтобы сделать их доступными для нашей связанной работы. Вот execute()метод работы:
public void execute(Context context) throws Exception {
// grab the configured FTP config key for the job
// and pass it on to the chained FTP/archive job
context.saveJobResult("ftpConfigKey",
context.getConfig().getString("ftpConfigKey"));
for (File file : toGenerate) {
// ... some code to generate the file
// when successful, save the output
// (multiple saved to the same name is fine)
context.saveJobResult("generatedFile", file.getAbsolutePath());
}
}
Довольно простые вещи. Самое интересное здесь — это первая строка. Чтобы сделать цепное задание FTP / архива действительно пригодным для повторного использования, мы настроили наше файловое задание с помощью ключа, который мы можем использовать для загрузки соответствующей конфигурации FTP, используемой для передачи файлов. Затем мы передаем это значение конфигурации на задание FTP в качестве результата задания, чтобы нам не приходилось настраивать отдельное задание FTP для каждой конечной точки FTP. Однако настройка отдельного задания FTP для каждого FTP-сайта — это еще один доступный вариант, в этом случае вам не придется настраивать файловое задание с помощью ключа конфигурации или включать эту первую строку.
Далее мы увидим, как получить доступ к этим выводам в задании FTP / архив, а после этого, как настроить конфигурацию цепочки.
FTP / Архив работы
Эта работа имеет две ключевые особенности:
- Он загружает конфигурацию FTP на основе ключа FTP, переданного исходным заданием.
- Он просматривает все сгенерированные файлы и обрабатывает их соответствующим образом.
Обратите внимание, что все результаты работы сохраняют свой тип Java при загрузке в цепочечную работу, хотя они возвращаются как List<Object>. Примитивы поддерживаются как выходные значения, а также любой тип, имеющий открытый конструктор, который принимает String( toString()используется для сохранения значений).
public void execute(Context context) throws Exception {
Map<String, List<Object>> sourceJobResults = context.getSourceJobResults();
List<Object> fullFilePaths = sourceJobResults.get("generatedFile");
if (fullFilePaths != null) {
if (sourceJobResults.get("ftpConfigKey") == null) {
// ... maybe fail here depending on your needs
}
String ftpConfigKey = (String) sourceJobResults.get("ftpConfigKey").get(0);
FTPConfig config = loadFTPConfig(ftpConfigKey);
for (Object filePath : fullFilePaths) {
File f = new File((String) filePath);
// ... some code to transfer and archive the file
// Note that this step ideally can deal with already processed files
// in case we need to resubmit this job after failing half way through.
}
}
}
Опять же, это довольно просто. Мы берем сохраненные результаты из исходного задания и строим нашу логику вокруг него. Как упомянуто в комментариях, в реализации, подобной этой, нужно учитывать одну вещь, если обработка завершается неудачно после обработки только некоторых результатов. Возможно, вы захотите просто повторно выполнить невыполненное задание в таком случае, чтобы оно могло быть выполнено повторно, не вызывая проблем. Обратите внимание, что это не проблема, если у вас есть только один файл для обработки.
Конфигурация цепочки
Теперь, когда рабочие места можно использовать повторно, вот как настроить цепочку. Вот как это выглядит в интерфейсе:
Мы используем условную цепочку здесь, чтобы указать, что нам нужно цеплять работу только тогда, когда generatedFileсуществуют значения для . Кроме того, мы гарантируем, что ftpConfigKeyзначение установлено. Настоящая красота этого в том, что Obsidian отслеживает, почему он не сковал работу, если он не соответствует настройке цепочки. Например, если ftpConfigKeyне было настроено, задание FTP / Архив все равно будет иметь подробную запись истории с состоянием «Пропущена цепь» и подробное сообщение, подобное этому:
Обратите внимание, что в этом примере не требуется, чтобы мы делали условную цепочку, так как наше задание FTP / архив обрабатывает, когда нет значений для generatedFile, но это все еще хорошая практика, если у вас есть уведомления, которые выходят после завершения задания. Это также делает вашу подробную историю более информативной, что может помочь вам с устранением неполадок. Если вы не хотите использовать условную цепочку, вместо этого вы можете просто выполнить цепочку в состоянии Completed.
Вывод
Obsidian предоставляет мощные функции связывания, которые были специально разработаны для максимизации производительности и надежности. Наша работа заключается в том, чтобы сделать вашу жизнь проще как разработчик, оператор или системный администратор, и мы постоянно ищем способы улучшить продукт и предоставить ценности для нашего пользователя.
Если у вас есть вопросы по поводу приведенных выше примеров, сообщите нам об этом в комментариях.