Эффективный анализ EDI в базе данных в С#

75
8

3+ лет назад нам было предложено в срочном порядке разработать решение EDI для клиента.

Они хотели получить полный IP/контроль и т.д. Решения и не хотели использовать бесплатные решения с открытым исходным кодом, платить большие суммы денег для подобных BizTalk и т.д., Или платить постоянные сборы в VAN.

В то время мы проводили некоторые исследования и на самом деле не находили много информации о форматах EDI, синтаксическом анализе и т.д., Поэтому наша команда разработчиков из 2 человек просто вскочила и разработала решение на С#/ASP.Net. Из-за небольшого количества транзакций сообщений EDI, которые будут иметь место (100 или около того в день), мы приняли процесс RegEx для синтаксического анализа, проверки и вставки в базу данных. Это было сделано с помощью отдельного приложения С#, которое планировалось запустить каждые несколько минут и подключалось к клиентам различными провайдерами FTP, AS2, EBMX для обмена и загрузки данных, а также для загрузки любых исходящих сообщений EDI.

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

Теперь клиент хочет, чтобы еще одна работа EDI была сделана для другого пути их бизнеса, однако на этот раз транзакции edi-сообщений перескочили в 1000-е. Наши команды разработчиков относятся к использованию RegEx. Недавно я читал, что использование RegEx для разбора EDI имеет огромные накладные расходы и их следует избегать.

Единственная причина, по которой мы его приняли, в первую очередь, заключалась в неопытности незнания того, что лучше всего использовать. Тем не менее, RegEx запустил управление шаблонами сообщений edi, включая проверку в шаблонах. Клиент добавил еще несколько поставщиков в свои книги, и мы смогли добавить новые шаблоны сообщений (с пользовательскими изменениями) за считанные минуты.

После гораздо большего количества исследований в последнее время мы обнаружили, что большинство решений анализируют файлы EDI в XML. Для этого есть причина? Это просто принять более общий формат и/или избежать доступа к базе данных? Быстрее ли просто анализировать XML по сообщениям EDI с плоским файлом?

Мы хотим, чтобы элементы данных из файла EDI находились в базе данных? Разве мы просто проанализируем XML файл? Разве это не очередной шаг обработки, которого можно было бы избежать?

Прошу прощения за общий характер моего вопроса, но мне трудно найти ответы.

Большое спасибо за ваше время.

ПРИМЕЧАНИЕ. Наша команда разработчиков использует только продукты Microsoft, поэтому, пожалуйста, учтите это при обращении.

спросил(а) 2013-03-08T13:03:00+04:00 8 лет, 1 месяц назад
1
Решение
97

Я подозреваю, что большинство разработчиков, которые решили написать собственное решение, написали свои собственные классы для преобразования EDI в XML, поскольку их интеграция с конечной точкой поддерживала XML (или они не могли напрямую записывать данные в db или хотели использовать XSLT, чтобы показать конечным пользователям данные красиво). Я написал парсеров, которые "переводились" в CSV и плоские форматы файлов, потому что это нам нужно было импортировать. Я также написал синтаксические анализаторы, чтобы сбрасывать их непосредственно в базу данных. Анализ в XML обычно представляет собой необходимый шаг для некоторых, как подход "промежуточного ПО". Если вам не нужно делать промежуточный шаг, то зачем вам? Если вы можете записать его в БД, обязательно сделайте это. Вы также не указали, какие документы вы делаете, и я предполагаю, что вы создали процесс FA в своем приложении. RegEx должен продолжать работать для вас, и есть много способов скинуть кошку.

С учетом сказанного, мой обычный отказ от ответственности применяется. Вы изобретаете колесо здесь. Милями. Я понимаю ваши пожелания клиента и рад, что вы смогли удовлетворить эту потребность. Честно говоря, я, вероятно, уволил бы клиента :) Поскольку вы используете только продукты Microsoft, вы как бы забиваете себя. Оглядываясь вокруг, BizTalk более обсуждается, чем другие пакеты. Вероятно, для этого есть причина, и, как вы узнали, это тоже очень дорого. Я большой поклонник Delta Liaison - работает в Windows, использует основные классы Microsoft Foundation и позволяет вам переводить любой из них на часть стоимости BizTalk. Кажется, что сохранение "карт" перетаскивания проще, чем сохранение тысяч строк кода, но эй, политика - политика :) Надеюсь, это поможет.

ответил(а) 2013-03-08T18:19:00+04:00 8 лет, 1 месяц назад
137

Около 3 лет назад я также создал парсер x12, который анализирует x12 edi в xml. В настоящее время он доступен с открытым исходным кодом на http://x12parser.codeplex.com. Причина, по которой я это делал, состояла в том, что я хотел, чтобы часть разбора не заботилась о цели, будь то база данных или, возможно, плоские файлы. Оказывается, это было ценно, так как некоторые пользователи использовали Oracle вместо Sql Server, и многие пользователи сглаживали его в плоские файлы для загрузки в свою базу данных или отправки в какой-то процесс вниз. Я думаю, что это сделало парсер очень гибким для многих сред. Другая причина, по которой мне понравился XML, - это то, что я смог добавить другие аннотации, которые были ценны для всех, у кого не было сохранено все коды EDI (в основном все), и я смог преобразовать его в HTML (см. Сайт для пример) с этими аннотациями. Я также создал возможность разделить ваши объекты на отдельные сообщения, чтобы ваша почтовая обработка могла потреблять по одному объекту за раз. Многие пользователи помогли мне оптимизировать его, чтобы он обрабатывал огромные файлы, поэтому он стал довольно стабильным. Сейчас я занимаюсь техническим обслуживанием, чтобы поддерживать все транзакции 4010. Часть о разборе в базе данных, которую я оставляю пользователю, потому что все, кажется, очень подробно относятся к тому, как они проектируют таблицы данных (например, я не мог согласиться с коллегой о том, следует ли использовать ints или GUID для идентификаторов таблиц, те, кто склоняется к менталитету DBA, предпочитают ints, те, кто использует много ORM, предпочитают GUID).

Вскоре после того, как я разместил это, я добавил базу данных, поэтому вы можете пропустить XML и перейти непосредственно к базе данных SqL Server. Вы можете решить, сколько сегментов будет анализироваться в отдельных таблицах, чтобы вы не раздували вашу базу данных с 300 таблицами, из которых вы, вероятно, будете использовать только 10 или 20. Здесь обсуждается SQL Server как промежуточная среда для профи и минусы использования xml или sql-сервера в качестве вашего посредника для вашей окончательной системы.

ответил(а) 2013-03-19T05:19:00+04:00 8 лет назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема