Р е п у б л и к а б ъ л г а р и я министерство на транспорта
Входна точка от ЕСОЕД към АИС 1.8Дефиниция
Изтегляне 0.53 Mb.
|
- Навигация на страницата:
- 1.9Сценарии и обработка на грешки
- 1.10Допълнителни изисквания
- 1.11Максимално допустимо време за сесия
- 1.12Идентификатори и допълнителни данни
Входна точка от ЕСОЕД към АИС1.8ДефиницияВходната точка към АИС е уеб услуга, имплементираща WSDL-а дефиниран в началото на документа. Този WSDL се използва и от всяка АИС, за да имплементира входна точка, която може да се вика от ЕСОЕД (КК). Уеб услугата трябва да има входна точка от тип SOAP 1.2 както е показано във WSDL дефиницията по-горе. 1.9Сценарии и обработка на грешкиУеб услугата съдържа само един метод, който има един параметър за вход и връща низ. Входният параметър е UTF-8 кодирано XML съобщението, което се изпраща. Резултатът е UTF-8 кодирано XML съобщението, което се връща. По-долу са разгледани точните входно съобщение и изходно съобщение за всеки сценарий:
В този случай АИС вика уеб услугата, имплементирана от КК и изпращаното съобщение се подава като входен параметър, а като резултат АИС ще получи EsoedResponse или EsoedError.
В този случай КК вика уеб услугата на АИС и входният параметър е изпращаното съобщение от комуникационния сървър към АИС, а АИС е длъжна да върне съобщение от тип DocumentReceipt, потвърждавайки, че технически е получила съобщението.
В този случай КК вика уеб услугата на АИС и входният параметър е съобщението от тип EsoedError, а АИС е длъжна да върне празен низ.
В този случай КК вика уеб услугата на АИС, като входния параметър е съобщение от тип DocumentReceipt, а АИС е длъжна да върне като резултат празен низ. Планирано е в определени случаи да се връща празен низ, както това е описано по-горе. Прави се, когато не е необходимо да се върне подписано съобщение по правилата на този протокол и е необходимо само технически да е ясно, че е получено съобщението. Във всички случаи, ако възникне грешка, е очаквано при грешка в процеса на работа (например отказ за вписване), да се изпрати отделен документ, описващ събитието. Грешките, възникнали по време на работния процес не са в обхвата на тази спецификация, тъй като протокола дава възможност за тяхното изпращане, но не ги различава от нормални документи. При технически грешки се очаква страните да подават и обработват SOAP грешки, както е дефинирано в стандарта. При грешки, свързани с получаването на документ от ЕСОЕД, се връща подписано съобщение от тип EsoedError. Съобщението от тип EsoedError се праща и до електронната поща на АИС на изпращащия участник. Пълен списък на възможните грешки при този тип съобщение ще бъде създаден допълнително като приложение към тази спецификация.
1.11Максимално допустимо време за сесияСъгласно чл. 14 от „Наредба за изискванията към ЕСОЕД” всяка сесия на обмен трябва да има максимално допустимо време, за което трябва да приключи. В текущата версия на този документ това не е строго дефинирано. Препоръчително е това време да бъде 2 часа, което е дефинирано на база резултати от проведени тестове. Така системата ще е устойчива на краткотрайни сривове, без да се бави повече от необходимото преноса на документи. Трябва да се има предвид, че по време на оперирането на ЕСОЕД, допустимото време за сесия на обмен може да бъде увеличавано или намалявано, в зависимост от технологичните особености на средата. 1.12Идентификатори и допълнителни данниСхемата за комуникация чрез ЕСОЕД съдържа няколко идентификатора, като всеки от тях има специфично предназначение. Те са описани в секция 3.5, а тук са дадени допълнителни пояснения за сценариите, в които се използват:
Това поле се използва за идентификация на всеки пренос. То се генерира от комуникационния сървър на ЕСОЕД и се съдържа във всяко съобщение, което е част от съответния пренос, независимо дали е генерирано от ЕСОЕД или АИС. Схема на действие: Когато АИС създава съобщение тип Document (било то заявка за услуга, отговор по заявка, status report или друго), той оставя това поле празно. Когато АИС изпраща този документ към ЕСОЕД (КК), в синхронния отговор получава стойността за SessionID, която ЕСОЕД поставя в EsoedDetails\SessionID. Когато АИС получи допълнителни съобщения по преноса на този документ (DocumentReceipt или EsoedError), те ще имат същата стойност в полето SenderDetails\SessionID. По този начин се идентифицира кой DocumentReceipt / EsoedError за кой пренос се отнася. Съответно когато даден АИС получи съобщение тип Document и отговори с DocumentReceipt, той поставя в SenderDetails\SessionID стойността, която е записана в полето EsoedDetails\SessionID на получения документ.
Това поле и следващото не са от значение за ЕСОЕД или за самия пренос през ЕСОЕД, но подпомагат АИС на участниците в процеса на корелация. CorrelationId се използва, за да може АИС да определи лесно и бързо на кое запитване отговаря даден отговор. По текущата нормативна уредба (Чл.4) подобно съпоставяне не е задължение на ЕСОЕД, но то се предоставя за улеснение на АИС, като ЕСОЕД не прави проверка за съответствие, а само подпомага съответния АИС при изпълнението на електронни услуги. CorrelationId се генерира от комуникационния сървър на ЕСОЕД и трябва да се съдържа не само във всяко съобщение за преноса - запитване, но и в съобщенията от преносите, съдържащи отговори на запитването. Ако това поле липсва, единствения начин АИС на участник да направи връзка между два разделно получени документа е като анализира специфичните данни в тялото на отговора, което е изключително трудоемко и непрактично, а в някои случаи дори недостатъчно. Схема на действие: Когато АИС на участник създава съобщение тип Document, с което заявява изпълнението на услуга от друга АИС участник, той оставя това поле празно. Когато АИС изпраща този документ към ЕСОЕД (КК), в синхронния отговор получава стойността за CorrelationId, която комуникационния сървър на ЕСОЕД поставя в EsoedDetails\CorrelationId. Когато АИС получи други документи, свързани с дадения документ (отговор на заявката, отказ за изпълнение на услуга, status report и т.н.), те ще имат същата стойност в полето SenderDetails\CorrelationId. По този начин се идентифицира кой отговор/отказ за коя заявка за услуга се отнася. Съответно, когато даден АИС получи документ със заявка за услуга, когато генерира документ за отговор, отказ, или status report, той поставя в SenderDetails\CorrelationId стойността, която е записана в полето EsoedDetails\CorrelationId на документa-заявка. 
Фигура 2
Както и CorrelationId това поле не е от значение за ЕСОЕД, но подпомага АИС на участника и последващ анализ на изпълнението на комплексни услуги. То съдържа допълнителни данни, попълнени от АИС на изпращащия участник. За разлика от предишните две полета, то не се генерира от ЕСОЕД, а от АИС. Въпреки че може да се използва с различни по функционалност идеи, полето е добавено в схемата, за да адресира един конкретен сценарий – възможността да се проследява информация, свързана с изпълнението на комплексни услуги. Когато има една комплексна услуга, тя се свежда от някой АИС на участник до изпълнението на множество други услуги. В този случай SessionId ще е различно за всеки пренос, CorrelationId ще е различно за всяка услуга и OriginatorExtraData може да е едно и също за комплексната услуга и всички нейни под-услуги, които се изпълняват. Схема на действие: Схемата е аналогична на горната с изключение на това, че OriginatorExtraData се генерира от АИС на изпращащия участник. OriginatorExtraData се използва, когато АИС генерира съобщения тип Document, с които заявява изпълнението на услуги от други АИС и тези услуги са част от една комплексна услуга. В този случай АИС, който „оркестрира” комплексната услуга (инициира изпълнението на простите услуги) поставя в полето OriginatorExtraData генериран от него идентификатор, който ще му позволи впоследствие да идентифицира всичките отговори по тази услуга. Съответно, когато даден АИС получи заявка за услуга, в която има попълнено поле OriginatorExtraData, той го копира в документа – отговор по тази заявка.
Каталог: upload -> docs docs -> Задание за техническа поддръжка на информационни дейности, свързани с държавните зрелостни изпити (дзи) – учебна година 2012/2013 docs -> Наредба №2 от 10. 01. 2003 г за измерване на кораби, плаващи по вътрешните водни пътища docs -> Наредба №15 от 28 септември 2004 Г. За предаване и приемане на отпадъци резултат от корабоплавателна дейност, и на остатъци от корабни товари docs -> Общи положения docs -> І. Административна услуга: Издаване на удостоверение за експлоатационна годност (уег) на пристанище или пристанищен терминал ІІ. Основание docs -> I. Общи разпоредби Ч docs -> Закон за изменение и допълнение на Закона за морските пространства, вътрешните водни пътища и пристанищата на Република България docs -> Закон за предотвратяване и установяване на конфликт на интереси docs -> Наредба за системите за движение, докладване и управление на трафика и информационно обслужване на корабоплаването в морските пространства на република българия Изтегляне 0.53 Mb. Сподели с приятели:
|
