<<

стр. 3
(всего 5)

СОДЕРЖАНИЕ

>>

16
Да

Таблица: SYNDICATION_SERVER_URL
Описание
Поле
Тип
Длина
Ненулевое
Описание
VALUE
VARCHAR2
4000
Да

Таблица: SYNDICATION_USERNAME
Описание
Поле
Тип
Длина
Ненулевое
Описание
VALUE
VARCHAR2
4000
Да

Таблица: TMODEL
Описание
Поле
Тип
Длина
Ненулевое
Описание
TMODEL_KEY
VARCHAR2
41

NAME
VARCHAR2
765

OVERVIEW_URL
VARCHAR2
765
Да
OPERATOR
VARCHAR2
765

AUTHORIZED_NAME
VARCHAR2
765

STATUS
NUMBER
1

MODIFY_TIMESTAMP
TIMESTAMP(6)
11


Таблица: TMODEL_CATEGORY_BAG
Описание
Поле
Тип
Длина
Ненулевое
Описание
OWNER_KEY
VARCHAR2
41

KREF_ORDER
NUMBER
28

TMODEL_KEY
VARCHAR2
41

KEY_NAME
VARCHAR2
765
Да
KEY_VALUE
VARCHAR2
765


Таблица: TMODEL_DESCRIPTION
Описание
Поле
Тип
Длина
Ненулевое
Описание
OWNER_KEY
VARCHAR2
41

DESCRIPTION_ORDER
NUMBER
28

DESCRIPTION
VARCHAR2
765
Да
LANGUAGE
VARCHAR2
8
Да

Таблица: TMODEL_IDENTIFIER_BAG
Описание
Поле
Тип
Длина
Ненулевое
Описание
OWNER_KEY
VARCHAR2
41

KREF_ORDER
NUMBER
28

TMODEL_KEY
VARCHAR2
41

KEY_NAME
VARCHAR2
765
Да
KEY_VALUE
VARCHAR2
765


Таблица: TMODEL_INSTINFO
Описание
Поле
Тип
Длина
Ненулевое
Описание
INSTINFO_KEY
VARCHAR2
32

BINDING_KEY
VARCHAR2
41

INSTINFO_ORDER
NUMBER
28

TMODEL_KEY
VARCHAR2
41

INSTANCE_PARMS
VARCHAR2
765
Да
OVERVIEW_URL
VARCHAR2
765
Да

Таблица: TMODEL_INSTINFO_DESCRIPTION
Описание
Поле
Тип
Длина
Ненулевое
Описание
OWNER_KEY
VARCHAR2
32

DESCRIPTION_ORDER
NUMBER
28

DESCRIPTION
VARCHAR2
765
Да
LANGUAGE
VARCHAR2
8
Да

Таблица: TMODEL_ODOC_DESCRIPTION
Описание
Поле
Тип
Длина
Ненулевое
Описание
OWNER_KEY
VARCHAR2
41

DESCRIPTION_ORDER
NUMBER
28

DESCRIPTION
VARCHAR2
765
Да
LANGUAGE
VARCHAR2
8
Да

Таблица: UPDATE_JOURNAL
Описание
Поле
Тип
Длина
Ненулевое
Описание
LOCAL_USN
NUMBER
19

ORIGINATING_USN
NUMBER
19

ORIGINATING_NODE
VARCHAR2
108

AUTHORIZED_NAME
VARCHAR2
765

UPDATE_TYPE
NUMBER
2

MODIFY_TIMESTAMP
TIMESTAMP(6)
11

CHANGE_DETAIL
CLOB
4000
Да
OFFENDING_CHANGE_RECORD
CLOB
4000
Да

Таблица: USER_PROFILE
Описание
Поле
Тип
Длина
Ненулевое
Описание
ID
VARCHAR2
192

AUTHORIZED_NAME
VARCHAR2
765


Таблица: VERSION
Описание
Поле
Тип
Длина
Ненулевое
Описание
PRODUCT
VARCHAR2
128
Да

Таблица: SCHEDULER_PROPERTIES
Описание
Поле
Тип
Длина
Ненулевое
Описание
PROPERTY_NAME
VARCHAR2
4000
Да
PROPERTY_VALUE
VARCHAR2
4000
Да
PROPERTY_DESCRIPTION
VARCHAR2
4000
Да

Репозитарий
Репозитарий является компонентом ядра Среды и предназначен для хранения информации о составе информационных ресурсов и используемых метаданных. В репозитарии хранится информация о структурах данных, используемых при реализации ПЭВ и вызовах внутренних web-сервисов.
Информация о типе данных включает:
* описание структуры данного типа (XSD);
* указание типа данных, являющегося каноническим для данного типа;
* набор инструкций для преобразования данных описываемого типа к каноническому виду и обратно (XSLT или процедура на языке Java);
* наборы инструкций для полного или частичного преобразования данных описываемого типа к любому другому типу и, возможно, обратного преобразования. Указание имени Java-класса и набора параметров, осуществляющего преобразование (по умолчанию указывается имя класса ru.ifirst.er.repository.XSLTTransformer с указанием имени XSLT-файла, содержащего инструкции для преобразования);
* техническое описание типа данных и его свойств на русском языке для администратора Среды (неструктурированная справочная информация - текст, графика).
В репозитарии могут быть размещены описания типов данных, являющимихся значениями классификаторов (xsd:simpleType), поэтому при внесении такого типа в базу репозитария, сервис репозитария выполняет проверку наличия такого классификатора в базе сервиса ССК и, если такой классификатор имеется, в дальнейшем выполняется проверка события (перехват) подсистемы ССК с тем, чтобы блокировать попытки удаления классификаторов, объявленных в репозитарии.

В состав репозитария входит: сервис репозитария, API репозитария.

Сервис репозитария
Сервис репозитария реализует следующие основные функции:
* проверка наличия в репозитарии описания типа (осуществляется путем проверки наличия в репозитарии пространства имен, содержащего описание указанного типа).
* выборка множеств типов в соответствии со сложными критериями поиска, описывающими условия, накладываемые на значения параметров типов, принадлежность типов к ветвям ССК, принадлежность их к пространствам имен. Критерии поиска могут быть построены на основе разнообразных операций (больше, меньше, равно, вхождение подстроки, соответствие шаблону регулярного выражения и т.д.);
* автоматическое преобразование данных зарегистрированных типов в ходе функционирования Среды;
* внесение информации о новых типах данных, ее изменение и удаление;
* получение основной информации о зарегистрированных типах (структура, канонический тип, инструкции преобразования к каноническому типу и обратно);
* получение инструкций о преобразовании зарегистрированных типов к любым другим типам, за исключением канонического, и обратно;
* получение справочной информации о зарегистрированных типах;
* поддержка наследственности типов данных;
* обращение к подсистеме ССК для получения описания (формата) указанного типа данных;
* экспорт/импорт описаний данных;
* откат инициированных действий при сбойных ситуациях и возобновление при их устранении;
* завершение сеанса работы пользователя репозитария;
API Репозитария
API репозитария представлено интерфейсом RepositoryService, который так же доступен как веб-сервис по SOAP-протоколу.

public class ru.ifirst.er.repository.service.RepositoryService

Конструкторы
public RepositoryService()

Методы
public java.lang.String transformXML(
String input,
String xsltLocation)
Преобразует входные XML-данные по заданной таблице трансформации

public boolean checkType(
String name)
Проверяет наличие типа в репозитарии

public java.lang.String transform(
String data,
String sourceType,
String destType)
Преобразует данные из одного типа в другой

public java.lang.String[] findTypes(
String query)
Осуществляет поиск типа по заданным параметрам

Структура данных репозитария
Репозитарий реализован на основе технологии RDF (). Поэтому физическая структура данных не отражает инфологической модели содержимого репозитария, т.к. основана на хранении RDF-примитивов. Приведена логическая структура репозитария.

Таблица: TYPES
Описание: Таблица типов
Поле
Тип
Длина
Ненулевое
Описание
NAME
string
255

DESCRIPTION
string
255

QNAME
string
255

CANONICAL
boolean


Таблица: NAMESPACES
Описание: пространства имен
Поле
Тип
Длина
Ненулевое
Описание
ID
integer

QNAME
CLOB

DESCRIPTION
string
255


Таблица: DOCUMENTS
Описание: документы в которых определены пространства имен
Поле
Тип
Длина
Ненулевое
Описание
URL
CLOB


Таблицы DOCUMENTS и NAMESAPCES связаны промежуточной маппинговой таблицей.

Таблица: TRANSFORMS
Описание: Таблица преобразований
Поле
Тип
Длина
Ненулевое
Описание
TYPE1
integer

TYPE2
integer

TRANSFORMER_CLASS
string
255

PARAMETERS
CLOB



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

Сервис сообщений является основным компонентом подсистемы оповещений и предназначен для предоставления другим сервисам Среды возможности обращения к функциям подсистемы оповещений. Сервис сообщений реализован на основе взаимодействия Java-компоненты реализующей интерфейс IMessagingService с внешними системами Cyrus IMAPD и Postfix. Вместо приведенных внешних систем могут быть использованы другие, для обеспечения совместной работы необходимо будет изменить реализацию сервиса оповещений - должен быть класс, имеющий интерфейс MessageServiceInterface.
API сервиса сообщений

public interface ru.ifirst.er.email.service.MessageServiceInterface


Methods
public void sendMail(
String from,
String[] to,
String replyTo,
String subject,
String content)
Отправляет почту, используя общие настройки СЭВ

public boolean createMailbox(
String userName,
String password)
Создает почтовый ящик в сторонней почтовой системе (имя класса реализации задается в конфигурационном файле)

public boolean deleteMailbox(
String name)
Удаляет почтовый ящик пользователя

public boolean updateMailbox(
String name,
String newName,
String newPassword)
Изменяет пароль на почтовый ящик пользователя


Структура данных подсистемы оповещений
Таблица: ODP_MAIL_ADDRESS
Описание
Поле
Тип
Длина
Ненулевое
Описание
FULL_NAME
string

EMAIL
string

PHONE
string

ADD_INFO
string


Таблица: ODP_MAIL_ADDRESS_GROUP
Описание
Поле
Тип
Длина
Ненулевое
Описание
name
string


Таблица: ODP_MAIL_FOLDER
Описание
Поле
Тип
Длина
Ненулевое
Описание
NAME
string
255

description
string
255

SUBJECT_FILTER
string
255

BODY_FILTER
string
255

FROM_SENT_DATE
timestamp

TO_SENT_DATE
timestamp

FROM_RECIVE_DATE
timestamp

TO_RECIVE_DATE
timestamp

COUNT_MESSAGE
int


Таблица: ODP_MAIL_MESSAGE
Описание
Поле
Тип
Длина
Ненулевое
Описание
MESSAGE_ID
string
255

SUBJECT
string
255

BODY
clob

HAS_ATTACHMENT
boolean

SENT_DATE
timestamp

RECEIVED_DATE
timestamp

FLAG
boolean




Портал СЭВ
Портал СЭВ обеспечивает пользовательский интерфейс для пользователей портала и администраторов.

Пользовательские компоненты:
1. Портлет голосований (включает администраторский интерфейс и построитель).
2. Лента новостей (включает администраторский интерфейс)
3. Контекстная помощь
4. UDDI-поиск
5. UDDI-публикация
6. Форма входа в систему, с возможностью смены пароля при утрате и размещения заявки на регистрацию в портале
Для авторизовавшихся пользователей:
7. Экран доступа к почтовому ящику (для зарегистрированных пользователей)
8. Список запущенных ПЭВов, с возможностью перехода к каждому экземпляру

Административные компоненты
1. Identity manager UI (управление пользователями, ролями, группами, привилегиями)
2. Настройки компонент (голосования, лента новостей, справочная система, UDDI-администратор)
3. Интерфейс администратора и оператора ССК
4. Интерфейс настройки репозитария
5. Консоль подсистемы исполнения ПЭВ
Интеграция веб-приложений в портал СЭВ
Основной задачей при интеграции веб-приложений в портал является получение информации о пользователе портала. При входе пользователя в портал создается клиентский COOKIE с номером сессии (SESSION_ID). Если веб-приложение размещается в том же домене, что и портал СЭВ, эти COOKIE будут доступны веб-приложению. SESSION_ID пользователя портала совпадает по значению с идентификатором сессии, зарегистрированной в подсистеме безопасности, поэтому полученный идентификатор сессии может быть использован сторонней системой для получения необходимой информации о пользователе (AuthorizationService.getUserInfo) и проведения других операций с помощью API СЭВ, требующих идентификатор сессии пользователя. При необходимости интегрировать систему, размещенную в другом домене, можно создавать ссылку (в меню портала, например, в качестве одного из параметров указав идентификатор сессии).
Для обеспечения безопасного обмена данными может использоваться SSL протокол, настройки SSL задаются в конфигурационном файле сервлет-контейнера Tomcat.
Структура данных портала
Таблица: CONTEXT_HELP_ARTICLE
Описание: Статья справочной системы
Поле
Тип
Длина
Ненулевое
Описание
TITLE
string
255

CONTENT
clob

CODE
string
10






Таблица: CONTEXT_HELP_TOPIC
Описание: Раздел справочной системы
Поле
Тип
Длина
Ненулевое
Описание
NAME
string
255


Таблица: VOTE_THEME
Описание: Голосование
Поле
Тип
Длина
Ненулевое
Описание
NAME
string
255

CREATEDATE
timestamp

STARTDATE
timestamp

ENDDATE
timestamp

MULTIPLE
boolean

ACTIVE
boolean


Таблица: VOTE_RESULTS
Описание: Результаты голосований
Поле
Тип
Длина
Ненулевое
Описание
INTERNAL_IP
string
255

EXTERNAL_IP
string
255

TIME
timestamp


Таблица: VOTE_LOCATION
Описание: Список допустимых размещений портлета голосований
Поле
Тип
Длина
Ненулевое
Описание
LOCATION
string
255



Таблица: VOTE_CHOICE
Описание: Варианты ответов для голосования
Поле
Тип
Длина
Ненулевое
Описание
TEXT
string
255


Таблица: NEWS
Описание: новости портала
Поле
Тип
Длина
Ненулевое
Описание
TITLE
string
255

CONTENT
clob

NEWS_DATE
timestamp



Требования к внутренним web-сервисам Среды электронного взаимодействия

Все регистрируемые в реестре сервисов Среды электронного взаимодействия web-сервисы информационных систем субъектов взаимодействия, предназначенные для интеграции информационных систем субъектов в рамках Среды, должны удовлетворять определенному набору требований, автоматически контролируемых в процессе регистрации в реестре таких сервисов. В дальнейшем, в целях отделения их от web-сервисов, реализующих процедуры электронного взаимодействия (ПЭВ), и прочих web-сервисов, описания которых хранятся в реестре, будем называть сервисы, предоставляемые субъектами взаимодействия в целях интеграции со Средой внутренними web-сервисами Среды. Внутренние сервисы Среды в большинстве случаев реализуются в виде электронных административных регламентов (ЭАР), поэтому будем в дальнейшем использовать термин ЭАР для обозначения таких сервисов.

Используемые при описании интерфейса ЭАР (внутреннего web-сервиса Среды) типы данных должны быть получены в результате импортирования опубликованных администратором Среды пространств имен.
Основные требования к web-сервисам

Разрабатываемый субъектом web-сервис должен обладать точками входа, позволяющими обратиться к его функциям. В зависимости от архитектуры web-сервиса, определяющей способ вызова его функций, описание этих точек входа осуществляется двумя способами.
1. В случае, когда обращение происходит синхронно (в частности, с использованием механизма RPC - возврат из метода web-сервиса осуществляется после полного завершения выполнения заданной функции) используется единственный метод, возврат из которого означает завершение работы сервиса. Первым параметром входного сообщения любого из таких методов должен быть идентификатор экземпляра ПЭВ, обращающегося к методу web-сервиса. Первым параметром выходного сообщения такого метода должен быть статус завершения работы метода (успешное завершение (RESULT_OK), внутренняя ошибка сервиса (RESULT_FAILED), экземпляр ПЭВ не имеет прав на обращение к сервису (RESULT_ACCESS_DENIED)). Так же возможно использовать стандартный механизм SOAP-fault для возврата ошибки.

<message name="ServiceRequest">
<part name="eip_id" type="string"/>
...
</message>

<message name="ServiceResponse">
<part name="result" type="string"/>
...
</message>

<operation name="Service">
<input message="ServiceRequest"/>
<output message="ServiceResponse"/>
</operation>

2. В случае, когда обращение происходит асинхронно (в частности, с использованием механизма обмена сообщениями - возврат из вызванного метода web-сервиса осуществляется немедленно) взаимодействие осуществляется согласно спецификации WS-Adressing [WSA].

При обращении некоторого экземпляра ПЭВ к web-сервису последний должен проверить, обладает ли данный ПЭВ правами на его запуск.

В процессе выполнения web-сервиса должен происходить обмен данными с пользователем посредством некоторого пользовательского web-интерфейса. Для этого в любой момент времени web-сервис должен обладать возможностью передать в Среду ссылку на web-интерфейс, предназначенный для получения от пользователя необходимой для выполнения сервиса информации. По получению необходимых данных от пользователя, сервис должен передать команду ПЭВ на продолжение исполнения процедуры.
Разрабатываемый субъектом web-сервис должен обладать методом, позволяющим остановить выполнение сервиса в рамках некоторого экземпляра ПЭВ.

Дополнительные требования к web-сервисам
Для большинства сервисов в любой момент до завершения выполнения web-сервиса в рамках некоторого экземпляра ПЭВ может быть произведен откат выполнения сервиса (бизнес транзакции или активности), т.е. сервис в рамках ПЭВ может быть приведен в исходное состояние.
Разрабатываемый субъектом web-сервис должен обладать методом, позволяющим произвести откат выполнения сервиса в рамках некоторого экземпляра ПЭВ к его первоначальному состоянию. Единственным параметром входного сообщения этого метода является идентификатор обратившегося к сервису экземпляра ПЭВ; единственным параметром выходного - результат попытки отката сервиса (откат сервиса произведен, откат сервиса не может быть произведен, сервис уже находится в процессе отката, обращение указанного экземпляра ПЭВ уже завершено и поэтому откат невозможен, обращение указанного экземпляра ПЭВ не происходило). Сервисы, откат которых непредусмотрен, должны обладать указанным методом, но всегда возвращать результат "откат сервиса не может быть произведен".

<message name="RollbackRequest">
<part name="eip_id" type="string"/>
</message>

<message name="RollbackResponse">
<part name="result" type="string"/>
</message>

<operation name="RollbackWS">
<input message="RollbackRequest"/>
<output message="RollbackResponse"/>
</operation>

В процессе развития программного комплекса Среды электронного взаимодействия и наращивания его функциональности требуется производить тестирование системы в реальном времени. Для осуществления такого тестирования разрабатываемый субъектом web-сервис для каждого метода, реализующего его функционал, должен обладать парным проверочным методом, позволяющим произвести проверку функциональности основного метода, не затрачивая реальные время и ресурсы на выполнение всех его действий. Параметры входного сообщения проверочного метода совпадают с параметрами входного сообщения основного метода, а выходное сообщение проверочного метода содержит все параметры выходного сообщения и результат тестирования сервиса (метод выполнен без ошибок, во время тестирования происходили внутренние ошибки сервиса, результат выполнения метода недостоверен, экземпляр ПЭВ не имеет прав на обращение к сервису).

<message name="ServiceTestRequest">
<part name="eip_id" type="string"/>
...
</message>

<message name="ServiceTestResponse">
<part name="result" type="string"/>
...
<part name="testresult" type="string"/>
</message>

<operation name="ServiceTest">
<input message="ServiceTestRequest"/>
<output message="ServiceTestResponse"/>
</operation>

Рекомендуемые спецификации

1) WS-I [http://www.ws-i.org/deliverables/]
2) WS-Coordination [http://msdn.microsoft.com/ws/2004/10/ws-coordination/]
3) WS-BusinessActivity [http://msdn.microsoft.com/ws/2004/10/ws-businessactivity/]

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

Общее описание
На рисунке представлена обобщенная схема основных компонент пилотного проекта "Общественная приемная".

Обозначения:
* Гражданин - формирующий запрос в МЭРТ и ожидающий ответ на свой запрос.
* СЭДО - система электронного документооборота.
* СЭВ - среда электронного взаимодействия.
* UI - пользовательский интерфейс портала СЭВ.
* ES - сервис исполнения СЭВ.
* AS - авторизационный сервис СЭВ.
* Шлюз - сервис, обеспечивающий передачу сообщений между ПЭВ и СЭДО.
* ПЭВ - Процедура электронного взаимодействия "Общественная приемная", он же собственно пилотный проект.
* ws - веб-сервис, описыннай с помощью WSDL, в соответствии со спецификацией WSDL [Ссылки 2];
* jsp - jsp-реализация пользовательского интерфейса [Ссылки 5];
Описание связей
Все взаимодействия между ПЭВ "Общественная приемная", Компонентами СЭВ, Шлюзом и СЭДО показаны стрелочками. Взаимодействие осуществляется с использованием различных протоколов, надпись на стрелочке указывает используемый протокол. Двунаправленная стрелка показывает, что взаимодействие является синхронным, а однонаправленная - асинхронным.
Используемые протоколы:
* soap - согласно спецификации SOAP [Ссылки 1];
* soap+wsa - согласно спецификации SOAP и WS-Addressing [Ссылки 6];
* http - согласно спецификации HTTP [Ссылки 7];
* jdbc - согласно спецификации JDBC [Ссылки 3];
Основные компоненты ПЭВ "Общественная приемная"
* BPEL script - описание бизнес-процесса ПЭВ "ОП". (ОП = Общественная приемная) [Ссылки 4];
* UI service - сервис, предоставляющий пользовательский интерфейс ПЭВ "ОП".
* Task - сервис, обеспечивающий асинхронное взаимодействие BPEL script с удаленным сервисом СЭДО и базой данных DB.
* Callback - сервис, обеспечивающий асинхронное взаимодействие с удаленным сервисом СЭДО.
* properties - сервис, поставляющий тест сообщений, которые показываются пользователю.
* msgs - файл с текстами сообщений.
* DB - база данных, в которой хранится текущие переменные ПЭВ: тексты запросов и ответов, файлы запросов и ответов, имена исполнителей, и др.
BPEL script
Ядром ПЭВ "ОП" является сценарий BPEL. В процессе своего исполнения, он взаимодействует с веб-сервисами как СЭВ, так и внутренними, которые обеспечивают решение необходимых в контексте исполнения задач. Подробное описание сервисов ES и AS находится в спецификации на СЭВ.
UI service
Сервис UI service обеспечивает решение следующих задач:
- формирование пользовательского интерфейса (веб-форм) для подачи гражданином запроса и выдачи ответа или отказа МЭРТ;
- сохранение текста и файла запроса в базе данных;
- предоставление BPEL сценарию URL-ов на веб-формы подачи запроса и ответа(отказа).

public class gui

Методы
public String getURL(
String peiSessionID);
Результат: URL на веб-форму, в зависимости от стадии, выдает URL на форму ввода запроса, или форму ответа (отказа) на запрос.
Параметры: peiSessionID - идентификатор сессии

Так же UI service состоит из набора jsp-страниц:
* create.jsp - реализует форму для ввода текста и фала запроса и сохраняет их в базе данных.
* answer.jsp - реализует форму для показа ответа на запрос гражданина.
* reject.jsp - реализует форму для показа ответа на запрос гражданина.

task
Сервис task обеспечивает решение следующих задач:
- получение полной информации о текущей стадии;
- участие в организации цикла ожидания ввода гражданином запроса;
- инициирование обращений к удаленному сервису СЭДО с целью передачи запроса и получения статуса исполнения запроса.

public class task

Методы
public String getFullInfo(
String peiSessionID);
Возвращает информацию о текущей стадии в текстовом виде. Результат передается сервису выполнения среды.
Параметр: peiSessionID - идентификатор сессии;
Результат: строка, содержащая полную информацию о данной стадии.

public void isTaskPosted(
String peiSessionID);
Учувствует в реализации цикла ожидания ввода запроса пользователем. Вызывается асинхронно.
Параметр: peiSessionID - идентификатор сессии.

public String postTask(
String peiSessionID,
String task_text);
Инициирует выполнение обращения к удаленному сервису СЭДО. В качестве параметра получает идентификатор сессии и текст запроса.
Параметры: peiSessionID - идентификатор сессии; task_text - текст запроса.
Результат: строка, в данной реализации не используется.

public void whatStatusNow(
String peiSessionID);
Инициирует запрос к удаленному сервису СЭДО с целью получения статуса выполнения. Вызывается асинхронно.
Параметр: peiSessionID - идентификатор сессии.

properties
Веб-сервис properties, является утилитой, поставляющей текстовую информацию для BPEL процесса, а так же интернационализацию ПЭВ "ОП".

Сервис task обеспечивает решение следующих задач:
- организация поставки текстовой информации для BPEL процесса.

public class properties

Методы
public String getProperty(
String key);
По заданному ключу возвращает текст. Как правило BPEL использует полученный текст для записи истории и комментариев в сервис исполнения.

callback
Учувствует в получении асинхронных ответов от удаленного веб-сервиса СЭДО.

public class callback

Методы
public void getDocumentContentResponse(
Document_out_files inf);
Получает асинхронный ответ с содержанием ответа или отказа на запрос гражданина от удаленного веб-сервиса СЭДО.
Параметр: inf - информация об ответе на запрос гражданина.

public void getDocumentStatusResponse(
Document_out out);
Получает асинхронный ответ со статусом выполнения запроса от удаленного веб-сервиса СЭДО.
Параметр: out - статус выполнения запроса гражданина в СЭДО.

public void processDocumentResponse(
Document_out out);
Получает асинхронный ответ с идентификатором запущенного в СЭДО процесса.
Параметр: out - статус выполнения запроса гражданина в СЭДО, формат тот же, что и у предыдущего метода, но важным является только идентификатор процесса.

Структура данных DB
В качестве RDBMS используется Oracle 9i Database 9.2.0.1.

Таблица: MESSAGE_2_PROCESS
Описание: маппинг идентификатора сообщения на идентификатор процесса
Поле
Тип
Длина
Ненулевое
Описание
PROCESS_ID
VARCHAR2
255

MESSAGE_ID
VARCHAR2
255


Таблица: TABLE PEI_2_FILES
Описание: информация о файлах запроса и ответа
Поле
Тип
Длина
Ненулевое
Описание
ID
VARCHAR2
255

PEI_ID
VARCHAR2
255

NAME
VARCHAR2
255

CONTENT
CLOB


Таблица: TASK_2
Описание: текст запроса, текст ответа/отказа, состояние обработки запроса, ответственный исполнитель
Поле
Тип
Длина
Ненулевое
Описание
ID
VARCHAR2
255

QUESTION
VARCHAR2
255

ANSWER
VARCHAR2
255

STATUS
VARCHAR2
255

CONDITION
VARCHAR2
255

USER_INFO
VARCHAR2
255

MAIN_EXECUTER
VARCHAR2
255


Таблица: TASK_SERVICE
Описание: корреляционная информация для асинхронных веб-сервисов
Поле
Тип
Длина
Ненулевое
Описание
PEI_ID
VARCHAR2
255
NOT NULL
REPLY_TO
VARCHAR2
255

MESSAGE_ID
VARCHAR2
255


Таблица: USER_2_PEI
Описание: информация о гражданине
Поле
Тип
Длина
Ненулевое
Описание
PEI_ID
VARCHAR2
255

U_NAME
VARCHAR2
255

U_MIDDLENAME
VARCHAR2
255

U_SURNAME
VARCHAR2
255

ADDRESS
VARCHAR2
255

PHONE
VARCHAR2
255

FAX
VARCHAR2
255

EMAIL
VARCHAR2
255




Реализация взаимодействия между ПЭВ и СЭДО

Принципы взаимодействия систем в процессе обработки обращения гражданина:


Действия ПЭВ
Действия СЭДО
Метод WEB-сервиса СЭДО, параметры на входе и выходе
1.
Обращения вводятся пользователем через интерфейс, предоставленный ПЭВ.
Получения данных о запросе и запуск процесса обработки документа - исполнение документа. СЭДО в ответ возвращает идентификатор запущенного процесса и его параметры.
Операция: ProcessDocument.
Вход: Тип процесса, данные о запросе
Выход: Идентификатор процесса, параметры процесса. В случае ошибки - код и описание ошибки.
2.
Отслеживание регистрации обращения
Чтение статуса процесса и ответ в ПЭВ
Операция: GetProcessStstus
Вход: Идентификатор процесса
Выход: Состояние процесса, идентификатор и данные о регистрируемом документе (номер, дата регистрации, состояние)
3.
Отслеживание процесса исполнения обращения
Чтение статуса процесса и ответ в ПЭВ
Операция: GetProcessStatus
Вход: Идентификатор процесса
Выход: Состояние процесса, идентификатор и данные о регистрируемом документе, данные о его исполнении - текущие исполнители резолюции, данные об исполнении резолюции, состояние исполнения резолюции.
4.
Отслеживание ответа
Чтение статуса процесса и ответ в ПЭВ
Операция: GetDocumentContent
Вход: Идентификатор процесса
Выход: Состояние процесса, идентификатор и данные о регистрируемом документе, данные о его исполнении - данные о документе "во исполнении", его регистрационные данные и содержание.

Ввод обращения гражданином.
Гражданин является инициатором обращения. Воспользовавшись пользовательским интерфейсом портала, Гражданин инициирует выполнение ПЭВ "Общественная приемная". После получения от гражданина ПЭВ формирует запрос в МЭРТ со следующими параметрами (примерное содержание обращения). Используется операция веб-вервиса СЭДО ProcessDocument:
Листинг 1
<document_in>
<template_name>Обращение гражданина</template_name>
<add_reg_info>
<addresse_from>
<person>
<first_name>Имя</first_name>
<middle_name>Отчество</middle_name>
<surname>Фамилия</surname>
<address>Адрес</address>
<phone>Телефон</phone>
<fax>Факс</fax>
<email>E-mail</email>
<note>Дополнительная информация</note>
</person>
</addresse_from>
<content>Обращение гражданина</content>
<note>Дополнительная информация</note>
</add_reg_info>
<files>
<file name="Обращение.txt">
Я, Гражданин Российской Федерации, направляю в Правительство
Российской Федерации жалобу... Подпись: Иванов Иван
Иванович.
</file>
</files>
</document_in>

Обязательно заполняются:
- Имя темплейта document_in/template_name (Обращение гражданина)
- Список отправителей document_in/reg_cart_info/addresse_from (Данные о гражданине)
- Краткое содержание document_in/reg_cart_info/content (Обращение гражданина)
- Запрос гражданина document_in/files/file (в виде файла с именем Обращение.txt)
Информация о Гражданине не специфицирована в схеме WSDL, и представляет собой строку с необходимой разметкой, как показано в Листинг 1.
На данное сообщение СЭДО отправляет ответ, содержащий идентификатор процесса (Листинг 2), или сообщение об ошибке (Листинг 3).
Листинг 2
<document_out>
<process>013ac84a-3759-4f2c-bceb-49f16ce2b4fa</process>
<process_condition>1</process_condition>
<reg_card_info>
<condition>0</condition>
</reg_card_info>
<execution_info/>
</document_out>

При этом ключевыми параметрами являются:
1) Идентификатор процесса: document_out/process/text();
Листинг 3
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:xml="http://www.w3.org/XML/1998/namespace">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>Error code</env:Value>
</env:Code>
<env:Reason>
<env:Text xml:lang="ru">Сообщение об ошибке</env:Text>
</env:Reason>
</env:Fault>
</env:Body>
</env:Envelope>

Отслеживание регистрации обращения.
После формирования сообщения с обращением гражданина и отправкой его в СЭДО, а так же получением из СЭДО идентификатора процесса, необходимо организовать цикл отслеживания регистрации документа в СЭДО. Используется операция GetDocumentStatus. Форма запроса о состоянии документа показана в Листинг 4.
Листинг 4
<status_request>
<process>525b15a6-c1fb-4818-9c9e-bf9c851e510f</process>
</status_request>

В ответ, операция СЭДО возвращает следующие данные (Листинг 5), в случае возникновения ошибки, СЭДО возвращает сообщение об ошибке (Листинг 3):
Листинг 5
<document_out>
<process>525b15a6-c1fb-4818-9c9e-bf9c851e510f</process>
<process_condition>1</process_condition>
<reg_card_info>
<condition>4</condition>
<reg_card_date>Дата регистрации</reg_card_date>
</reg_card_info>
<execution_info>
<main_executor>Ответственный исполнитель</main_executor>
<answer_text>Краткое содержание ответа</answer_text>
</execution_info>
</document_out>

Основными информационными параметрами на данном этапе являются:
- Идентификатор процесса: document_out/process/text();
- Состояние процесса: document_out/process_condition/text(), возможные варианты (1:Процесс обработки запущен, 2:Процесс обработки документа завершен, 3:Процесс обработки документа временно приостановлен), указывается кодом;
- Состояние: document_out/reg_cart_info/condition/text(), возможные варианты (1:Подготавливается, 2:Согласуется, 3:Регистрируется, 4:Исполняется,5:Исполнен), указывается кодом;
- Примечание: document_out/reg_card_info/note/text(). Содержит информацию о причине отказа.
- Дата регистрации: document_out/reg_cart_info/reg_card_date.
- Ответственный исполнитель: document_out/execution_info/main_excecutor/text().

ПЭВ, на основании наличия и значений данных параметров решает, что документ зарегистрирован, и сохраняет данное состояние в DB, после чего BPEL script начинает отслеживать процесс исполнения документа, или сразу перейдет в состояние просмотра отказа.

Отслеживание процесса исполнения обращения

После регистрации документа, ПЭВ инициирует цикл отслеживания процесса исполнения обращения гражданина. Используется операция GetDocumentStatus. Форма запроса о состоянии процесса исполнения документа показана в Листинг 6.
Листинг 6
<status_request>
<process>525b15a6-c1fb-4818-9c9e-bf9c851e510f</process>
</status_request>

В ответ, операция СЭДО возвращает следующие данные (Листинг 7), в случае возникновения ошибки, СЭДО возвращает сообщение об ошибке (Листинг 3):
Листинг 7
<document_out>
<process>525b15a6-c1fb-4818-9c9e-bf9c851e510f</process>
<process_condition>1</process_condition>
<reg_card_info>
<condition>4</condition>
<reg_card_date>Дата регистрации</reg_card_date>
</reg_card_info>
<execution_info>
<main_executor>Ответственный исполнитель</main_executor>
<answer_text>Краткое содержание ответа</answer_text>
</execution_info>
</document_out>

Основными информационными параметрами на данном этапе являются:
- Идентификатор процесса: document_out/process/text();
- Состояние процесса: document_out/process_condition/text(), возможные варианты (1:Процесс обработки запущен, 2:Процесс обработки документа завершен, 3:Процесс обработки документа временно приостановлен), указывается кодом;
- Состояние: document/reg_cart_info/condition/text(), возможные варианты (1:Подготавливается, 2:Согласуется, 3:Регистрируется, 4:Исполняется,5:Исполнен), указывается кодом;

<<

стр. 3
(всего 5)

СОДЕРЖАНИЕ

>>