#biztalk #edi
#biztalk #edi
Вопрос:
У меня есть приложение BizTalk, развернутое для сборки файлов X12 834. он отлично работает для сборки действительного файла EDI с примерно 100 тыс. записей, конечный сгенерированный файл составляет около 70-80 млн.
Но когда количество записей достигает примерно 1,2 млн, производительность службы пакетной обработки значительно падает, для завершения пакета требуется целая вечность.
Я попытался настроить пакетную обработку так, чтобы выпускать файл примерно для каждых 200 Тыс. обменов, он может генерировать несколько файлов, но производительность также изменилась на неприемлемую после того, как в нем появилось около 500 тыс. записей.
Я даже попытался запустить скрипт bts_CleanupMsgbox, чтобы очистить все в MsgBox перед запуском пакетной обработки.
Итак, возникает вопрос: может ли служба пакетной обработки BizTalk обработать такой объем данных? Проблема с производительностью просто вызвана дизайном службы пакетной обработки (сохранение в виде XML / сохранение состояния в базе данных во всех точках сохранения в оркестровке), или я могу архивировать для сборки файла с этим объемом данных с помощью некоторой настройки производительности.
Комментарии:
1. В некоторой степени это будет зависеть от объема памяти и процессора вашего сервера BizTalk и сервера баз данных. Однако хорошо известно, что при очень больших размерах сообщений в BizTalk возникают проблемы с производительностью. Возможно, вы можете выполнить некоторую настройку на экземплярах хоста, выполняющих пакетную обработку social.technet.microsoft.com/wiki/contents/articles /… и msdn.microsoft.com/library/dn775063 (v=bts.10).aspx
Ответ №1:
Я не думаю, что встроенная пакетная обработка подходит для таких объемов данных.
Есть ли какая-либо причина, по которой вам нужны такие большие пакеты? Я делаю довольно много EDI, но никогда не сталкивался с такими требованиями.
Я не знаю, применимо ли это для вас, но вы можете фактически обойти всю встроенную оркестровку пакетной обработки EDI, сопоставив схему X12InterchangeXml. Дополнительным преимуществом было бы то, что вы также можете контролировать порядок сообщений в обмене сообщениями. Для этого есть несколько хитростей, но в целом это может быть намного более производительным.
Комментарии:
1. То, что я делаю сейчас, — это обход службы пакетной обработки, отправляя каждую запись в виде отдельного файла EDI во временную папку, затем у меня есть службы Windows, которые собирают все эти файлы, а затем используют регулярное выражение для получения части содержимого (ST-SE), объединяя в один файл EDI.
2. Если я вас правильно понимаю: по сути, вы обрабатываете каждый файл не менее 3 раз. Это не очень полезно, так как вы говорите, что обработка выполняется очень медленно из-за ограничений ресурсов. Использование другого подхода может сэкономить вам много вычислительной мощности. Рассматривали ли вы пакетную схему X12 в этом местоположении «C:Program Файлы (x86) Microsoft BizTalk Server 2013 R2 XSD_Schema EDI X12_BatchSchema.xsd»?
3. Я не использовал эту схему напрямую. Но эта схема — это тип сообщения, сгенерированный службой пакетной обработки в моем понимании. Итак, вы предлагаете создать сообщение с помощью этой схемы с моей собственной оркестровкой?
4. Позвольте мне более четко объяснить мой текущий подход. Теперь я использую BizTalk для создания файлов EDI для каждой записи, это делается путем сопоставления схемы базы данных со схемой X12 и конвейера отправки EDI. когда все эти файлы будут созданы, служба Windows подберет эти файлы, удалит часть ISA-IEA и GS-GE, сохранит только часть ST-SE, объединит все эти ST-SE в один файл с новой упаковкой ISA-IEA и GS-GE. Подсчет значений ST-SE необходим для получения правильного значения GE01. Затем может быть сгенерировано допустимое значение X12,
Ответ №2:
Во-первых, вы должны дважды проверить преобладающие требования. 1,2 миллиона — это много, и у меня не так много 834. Не то чтобы этого не могло произойти, но 1,2 миллиона — это много для обеих сторон.
1,2 миллиона пользователей не шокируют, но 1,2 миллиона отдельных 834-х было бы очень, очень, очень необычно. Можете ли вы объединить ~ 10 тыс. или около того участников в 1 834? Тогда это всего лишь ~ 100 834.
Комментарии:
1. Джонс. Я не создаю 1,2 млн файлов 834, я создаю 834 файла, содержащих 1,2 млн элементов. И поскольку проблема с производительностью службы пакетной обработки, теперь мне нужно создать 1,2 млн временных файлов 834 и использовать службу Windows для их объединения.
2. Я имею в виду, что 834-й может содержать несколько членов, поэтому, если члены сгруппированы по 10 КБ на 834-й, вы используете только пакетную обработку BizTalk ~ 100 834.
3. понятно. Но это означает, что одно сообщение 834 содержит 10 тыс. участников. Размер сообщения будет огромным.
4. Но это будет меньше, чем 10 Тыс. отдельных 834-х записей только с одним участником. Есть ли у вас жесткое требование отправлять всю совокупность одновременно? Если нет, возможно, вы немного переоцениваете это.