Существует ли книга или какая-либо документация, описывающая лучшие практики для разработки пакетных (автономных) процессов для обмена данными между двумя сторонами?

Я нашел некоторую полезную информацию на сайте весенней партии, но это довольно низкий уровень:стратегии пакетной обработки а такжепринципы принципов партии.

Есть много соображений для партии, например:

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

Было бы хорошо, если бы был какой-нибудь авторский документ или контрольные списки, которые гарантировали бы, что проекты следуют лучшим практикам в этой области.

UPDATE: Я

Я добавлю ответы в этот раздел по мере их появления.

Общая партия / Офлайн обработка информации

Этот раздел взят из @ user1813068 'ответ.

Вы можете найти некоторые образцы архитектурного дизайна в этомссылка на сайт а также в этомссылка на сайт которые описывают подходы для интеграции между партнерами и для синхронизации данных.

Эта страница википедии также дает общий обзор архитектурных шаблонов и включает шаблоны для интеграции данных:архитектурные узоры.

КнигаПроект интеграции данных и моделирование тоже очень хорошо.

Дата файлы

Большая часть контента в этом разделе пришла отсюда:источник

Использование верхних и нижних колонтитулов для обмена плоскими файлами считается лучшей практикой. Плоские файлы могут быть обменены без верхних и нижних колонтитулов, а в именовании файла может содержаться некоторая информация из заголовка. При использовании файла с разделителями всегда требуется заголовок списка полей.

Заголовки

При обмене данными между системами для принимающей стороны очень важно точно знать, какой тип данных отправляется. Одним из способов обеспечения этого является предоставление строки заголовка, которая включает в себя соответствующую информацию, касающуюся содержимого данных и того, как они должны обрабатываться.

При работе с плоскими файлами само имя файла также может использоваться для информирования принимающей стороны о содержимом файла. Тем не менее, строка заголовка обеспечивает лучшую поддержку для всех доступных опций.

При работе с API эти поля заголовков могут быть предоставлены аналогичным образом. Реализация будет определяться разработчиком сервиса API.

Если заголовок включен, он состоит из одного набора данных и всегда должен быть первыми данными в файле.

колонтитулы

Нижний колонтитул может быть предоставлен при использовании файловых форматов, чтобы указать, что больше не осталось данных для обработки.

При обработке данные, найденные после строки нижнего колонтитула, следует игнорировать. Кроме того, при создании данных помните, что любые данные после строки нижнего колонтитула будут игнорироваться.

Форматы данных

Файлы с разделителями

Промышленный стандарт де-факто - файлы с разделителями.

Файлы с разделителями-запятыми (CSV или значения, разделенные запятыми) обычно требуют инкапсуляции данных, обычно с двойными кавычками ("); двойные кавычки должны быть экранированы либо с помощью обратной косой черты (), либо двойных двойных кавычек (""). Из-за несоответствий в реализации CSV рекомендуется использовать вкладки в качестве разделителя, без инкапсуляции. В этом случае символы табуляции должны быть удалены из данных. Файлы с разделителями обычно быстрее обрабатывают эти XML-файлы.

XML-файлы

В отрасли есть люди, которые предпочитают файлы XML. XML обеспечивает более четкое представление информации, поскольку поддерживает вложенные данные. Многие компании ограничивают или не поддерживают этот формат, поэтому это не рекомендуется.

кодирование

Кодировка UTF-8

Все данные должны быть в кодировке UTF-8 для обеспечения максимальной совместимости между всеми системами.

Даты и раз

Рекомендуется использовать время UTC для всей даты и поля времени, чтобы предотвратить путаницу.

Еще несколько лучших практик:Планирование EDI и передача файлов