2012-07-02 6 views
6

Мы современная компания, использующая современные технологии, такие как интерфейсы XML, но многие наши клиенты хотят, например, электронных счетов от нас в формате EDIFACT, таком как D96A.Есть ли действительно простой способ обработки EDIFACT, например D96A?

Нет, мы не можем использовать уже существующие библиотеки, так как они не написаны на языке программирования C/AL, используемом нашим программным обеспечением Navision.

Так что, чтобы разобрать его в C/AL, мне нужно понять его спецификацию. Но это выглядит чрезвычайно сложно и сложно.

Может ли кто-нибудь дать мне обзор, как интерпретировать D96A и как его разобрать?

ответ

0

Я знаю, что этот вопрос старше, но мне пришлось провести небольшое исследование для проекта клиента. Существует несколько хороших дополнений для Dynamics NAV. Например, посмотрите на Anveo EDI Connect, они внедрили импорт и экспорт EDIFACT (и многих других форматов) непосредственно в NAV. Другие решения доступны от BMI, Yaveon, Lanham и нескольких других компаний. Есть также несколько поставщиков услуг, которые обрабатывают данные, и вы соглашаетесь с ними в простой структуре XML или файла.

2

Я предлагаю искать и просматривать через репозитории GitHub или SourceForge. Быстрый поиск с ключевыми словами: + EDIFACT + D96A предоставил несколько библиотек на выбор. На самом деле это выглядит многообещающим для Вашего случая:

  • Боты с открытым исходным кодом еди переводчик, http://sourceforge.net/projects/bots/. В описании проекта говорится, что это полный переводчик для EDI (электронный обмен данными).

Вы всегда можете оценить и проверить Oracle 11g B2B, которая является частью Oracle SOA Suite 11gR1: - http://www.oracle.com/technetwork/middleware/soasuite/downloads/downloads-085394.html#11g. У него есть библиотека OTD UN/EDIFACT, которую, я думаю, вы можете использовать, по крайней мере, для синтаксического анализа.

Как правило, лучше всего выбрать существующую библиотеку и либо портировать ее в NAV, либо использовать через внешний интерфейс, где данные передаются в вашу базу данных NAV. Если вы можете вызвать .NET-код, тогда существует множество существующих библиотек, и просто путем ссылки на сборку вы попадете туда. Поскольку я не знаком с разработкой NAV, но используя какой-то REST/JSON, какой бы механизм обработки вызовов передачи данных не был возможен, - где ваш компонент B выполняет тяжелую работу, а ваш компонент NAV вытягивает разобранные сообщения UN/EDIFACT через ваш XML-интерфейс.

Был еще один подобный вопрос и ответы на вопросы, которые могут вас устраивать: Is there any good open source EDIFACT parser in Java?.

Ура!

9

Разбор ЭДИФАКТ на самом деле не такой уж сложный. Просто разделите на символы sytax: сначала на ', чтобы получить сегменты, чем на +, чтобы получить элементы данных этих сегментов и на :, чтобы получить отдельные компоненты. Разумеется, вам нужно позаботиться об эвакуированных символах-разделителях. Используемые здесь символы только по умолчанию, они могут быть изменены в начале сообщения дополнительным сегментом UNA. На самом деле wikipedia article на EDIFACT дает довольно хорошее (но краткое) введение к этому. И формат документируется с подробной информацией о UN's UNECE site (да, это много и трудно читать).

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

Но вот идея: если вы в значительной степени используете XML (или любую другую «современную технологию», как вы ее называете ...). Было бы относительно простой задачей написать некоторую программу, которая преобразует сообщения EDIFACT в какой-то единый формат XML-EDIFACT-Format (что довольно ужасно и, скорее всего, выйдет из себя). Вы можете конвертировать каждый сегмент EDIFACT в один XML-тег, может быть, как это:

ERC+A7V:1:AMD' 
IFT+3+NO MORE FLIGHTS' 

В XML:

<segment qualifier="ERC"> 
    <element> 
     <component>A7V</component> 
     <component>1</component> 
     <component>AMD<component> 
    </element> 
</segment> 
<segment qualifier="IFT"> 
    <element> 
     <component>3</component> 
    </element> 
    <element> 
     <component>NO MORE FLIGHTS</component> 
    </element> 
</segment> 

Затем вы можете раскрутить силу ваших инструментов и библиотек XML на нем, чтобы проверить/оценить Это.

Вы могли бы также сделать его более конкретным, например:

<segment_ERC> 
    <element> 
     <component>A7V</component> 
     <component>1</component> 
     <component>AMD<component> 
    </element> 
</segment_ERC> 
<segment_IFT> 
    <element> 
     <component>3</component> 
    </element> 
    <element> 
     <component>NO MORE FLIGHTS</component> 
    </element> 
</segment_IFT> 

Это может сделать проверку с помощью XSD проще. В этом разговоре вы можете получить, конечно, то, что вам нужно, но вы рано или поздно придете к делу, где вам нужно будет поместить информацию о структуре вашего в настоящее время разобранного сообщения в конвертер (поскольку это не так просто знаете, какие сегменты вложены в другие сегменты, группирующие их. Не только UNG, UNH и такие, но и некоторые группы сегментов, которые вы не видите напрямую).

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

Смежные вопросы