Документооборот online

Описание типового веб-сервиса

WSDL схемы вариантов реализаций веб-сервиса проекта ElOrder можно получить по адресам:

• http://elorder.optima.kiev.ua/ElOrderService.svc?wsdl

Обобщенная схема работы

В начале работы с сервисом клиент инициализирует сессию (авторизуется) на сервере посредством вызова метода Init, передавая ему информацию идентифицирующую клиента ─ код ОКПО и уникальный идентификатор компьютера.

Отдельно нужно отметить, что в данной схеме клиенту не требуется какой-либо специальной

регистрации, получения логинов-паролей у поставщика ─  по умолчанию клиенту доступно

только получение общего (публичного) прайс – листа. Полный функционал становится

доступным, когда менеджеры поставщика активируют данного клиента, убедившись в его

аутентичности.

Сервер проверяет «активированность»  данного ОКПО и компьютера и возвращает идентификатор сессии.

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

Сразу после авторизации клиент автоматически отправляет на сервер (UpdateDeliveryAddressesList) список своих новых и изменившихся точек доставки, отсылая пары

<уникальный идентификатор> – <полный почтовый адрес>. Эта информация используется поставщиком для более оперативного сопоставления точек доставки,  имеющихся у него в базе с теми, которые клиент будет указывать при создании заказов.

Этап сопоставления необходим, так как  гарантировать то, что клиент правильно и однозначно

укажет адрес, нельзя, а полная и проверенная информация о точках доставки уже есть в

базе поставщика.

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

Далее клиент продолжает работу, запрашивая прайс-лист, путем вызова метода GetPriceList.

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

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

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

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

Опрос очереди сообщений выполняется посредством регулярных вызовов клиентом метода

GetNewNotifications в течение  u1072 активности сессии.

При обработке очереди сообщений могут выполняться следующие операции:

• показ простого информационного сообщения пользователю

• изменение статуса заказа с показом соответствующего сообщения пользователю

• получение нового документа дефектуры с предложением вернуть его в потребность

Документ дефектуры получает путем отдельного вызова метода GetDocumentByUID с использованием идентификатора из соответствующего сообщения.

Типы данных

• UUID – строка длиной 36 символов без концевых фигурных скобок. Пример – 3605A06ED4E2-

4C14-B814-392540E3CE17. См. UUID

• DataContainer – объект-контейнер для данных со следующими атрибутами:

◦ IsCompressed – boolean

Булевый признак, показывающий, сжаты ли данные. Алгоритм сжатия – zip.

◦ Content – byte array

Массив бинарных данных, содержащий соответствующий документ в сжатом или распакованном виде. В типах WSDL – Base64Binary.

Описание методов

Init

Функция логина/подключения/авторизации клиента к сервису. Выполняется в начале работы. Инициирует сессию работы.

Параметры

• okpo – string.

Код ОКПО организации. При незаданном ОКПО отдается прайс на общих основаниях

• hardKey – string(32).

Уникальный идентификатор компьютера, генерируется на основе кода установки Windows и

CPU ID. Используется для ограничение количества клиентских мест для одного ОКПО.

• clientVersion – string.

Версия клиентского приложения.

Результат

Возвращает объект с атрибутами:

• SessionTicket – UUID.

Идентификатор сессии, в пределах которой выполняется вся работа с сервером. При возврате пустой строки (или строки 00000000-0000-0000-0000-000000000000 – особенность одной из реализаций) считается, что авторизация не выполнена.

• Content – string.

Дополнительные данные. Обычно представляет собой xml-документ с текстовыми сообщениями пользователю.

GetPriceList

Функция для получения специализированного прайс-листа. Ввиду большого объема прайс- листа данные обычно передаются в упакованном виде.

Параметры

• sessionTicket – см. SessionTicket

Идентификатор сессии, полученный на этапе авторизации.

• protocol – Integer

Версия протокола, которую поддерживает данный клиент. Пока существует лишь версия 1.

Результат

Возвращает DataContainer со сжатым xml-файлом прайс-листа.

GetNewNotifications

Функция для получения списка сообщений для u1076 данного ОКПО (не решено – только для ОКПО или еще и для HardKey) из очереди сервера. Вызывается клиентом с некоторой регулярностью (обычно раз в 2 мин.).

Параметры

• sessionTicket – см. SessionTicket

• protocol – см. protocol

• lastNotificationID – Int64

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

Результат

Возвращает DataContainer с xml-документом со списком разнотипных сообщений.

GetDocumentByUID

Функция для получения документа, произвольного типа по его идентификатору. На текущий момент используется лишь для получения дефектуры.

Параметры

• sessionTicket – см. SessionTicket

• protocol – см. protocol

• documentUID – UUID

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

Результат

Возвращает DataContainer с соответствующим документом.

UpdateDeliveryAddressesList

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

Параметры

• sessionTicket – см. SessionTicket

• protocol – см. protocol

• addresses – DataContainer

Список адресов точек доставки в виде xml-файла заданного формата.

Результат

Boolean

MakeOrder

Функция для отправки документа заказа на сервер.

Параметры

• sessionTicket – см. SessionTicket

• protocol – см. protocol

• order – DataContainer

Документ заказа в виде xml-файла.

Результат

Boolean

Форматы файлов

Кодировка – UTF-8 или win1251, но с обязательным ее указанием в заголовке xml.

Идентификаторы документов – типа UUID.

Формат дат и дробных фиксирован и описан в файле elorder_types.xsd в виде регулярных выражений. Примеры

DateTime – 10.01.2009 14:15:[12]

Date – 10.01.2009

Float – 145.45

Результат авторизации

Список сообщений

Пример – elorder_notify.xml

Схема – elorder_notify.xsd

Содержит очередь разнотипных сообщений для клиента. Список типов сообщений:

• TextNews

Текстовое сообщение, которое показывается пользователю.

• ChangesInOrderStatus

Сообщение с изменением статуса документа заказа и текстовым сообщением пользователю.

• DeficiencyInOrder

Сообщение о том, что для документа заказа, отосланного ранее, сформирован документ дефектуры.

Документ прайса

Пример – elorder_price.xml

Схема -

На текущий момент содержит минимум необходимой информации для уменьшения его размера.

Включает  список типов цен с их кодами, названиями и длительностью отсрочки.

Как расширение от компании «Оптима» может идти перечень акций (на данный момент не используется).

Документ заказа

Пример – elorder_order.xml

Схема – elorder_order.xsd

Для каждой точки доставки создается раздельный.

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

Документ дефектуры (отказа) поставщика

Пример – elorder_deficiency.xml

Схема – elorder_deficiency.xsd

Документ, содержащий перечень позиций из конкретного заказа, которые не могут быть поставлены.

Документ накладной

Пример – elorder_consignment.xml

Схема – elorder_consignment.xsd

Формат документа накладной находится в процессе согласования и окончательно не утвержден.

За основу при его разработке  брали формат mmo.

Информация о ценах из спец-прайсов может попасть к конкурентам

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

Какова выгода компании «Морион» в этом проекте?

- Выгода компании «Морион» – в поддержании репутации главного новатора фармрынка

Какова выгода поставщика при присоединении к этому проекту?

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

Зачем поддерживать этот стандарт, если у нас уже есть подобный механизм?

- Да, действительно, у многих поставщиков есть подобные системы заказа медикаментов. Но как показывает практика, один поставщик не может обеспечить аптеку необходимой ей номенклатуры препаратов и она работает с различными дистрибъюторами,  а использование разных программ для заказа не позволяет рознице сравнивать цены, да и работать во многих программах категорически! неудобно.