Алексей Багрянцев 3 октомври 2012 г

В процеса на работа многократно сме се сблъсквали с проблема с избора на решение за конкретен проблем. Понякога можете без много болка да приемете най-очевидния и често срещан метод, както се казва, „решаване на нещата директно“. В повечето случаи този подход ще даде резултати по един или друг начин, но може да изисква значителни умствени и времеви инвестиции от вас.

Ето защо, в ситуация, в която сте изправени пред нестандартна задача, може би си струва да се отдалечите от обичайните методи и да се опитате да обмислите няколко възможности, дори ако в началото те не изглеждат много успешни или просто не сте склонни да прибягвате към тях, защото „ние обикновено не правим това“. Основното тук е да не се страхувате да експериментирате, да тествате всеки метод и накрая да изберете най-подходящия, който отговаря на всички ваши нужди и осигурява необходимия резултат.

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

Фон

На един от PHP проектисреден размер имаше проблеми, свързани с извършването на тежки операции и интерактивно показване на състоянието на изпълняваната операция. В допълнение към блокирането на изпълнението на други заявки и кликването върху други връзки към портала, потребителят беше на тъмно и нямаше представа какво се случва в в моментавреме, когато операцията ще приключи, може да е възникнала грешка и т.н. Първоначално проектът имаше експериментален статус, изискванията за изпълняваните фази често се променяха в движение, приоритетите и векторът на развитие на системата се променяха. За да формирам по-добра представа, бих искал да опиша набора от технологии, използвани в проекта:

• MVC Framework CakePHP 2.1 (PHP5.3);
• MySQL;
• jQuery, jQuery UI, jQuery добавки;
• Selenium сървър, Snoopy сървърен симулатор на браузър;
• IMAP сървър и др.

като операционна системабеше избран: CentOS

Изборът на рамката се определя от опита от използването й от екипа за разработка, докато изборът на релационната СУБД MySQL като хранилище на данни е доста стандартно решение и се дължи на стабилността и широкото използване на тази СУБД като хранилище на данни „двигател“.

На етапа на проектиране на системата веднага беше трудно да се предвиди, че в системата ще се появят много „тежки“ операции, чийто процес на изпълнение ще трябва да бъде преразгледан, да се внедрят допълнителни компоненти и като цяло да се преработи архитектурата на приложението. Освен това системата беше един вид прототип, където изискванията често се променяха, както и къде системата щеше да се развива в бъдеще.

На един етап бяха внедрени редица операции, които се оказаха доста „тежки операции“ и не само блокираха изпълнението на други операции в рамките на същата сесия, но като цяло процесът на навигация през системните връзки стана невъзможен, докато „тежка“ операция не е завършена. При разглеждане на проблема на по-ниско ниво се оказа, че всяка заявка заключва файла на сесията, когато е отворен, съответно докато операцията не приключи напълно и процесът изчисти данните от сесията във файла на сесията и го освободи, като освободи заключване, други заявки търпеливо ще чакат на опашка. Наистина, по подразбиране PHP използва файл като механизъм за съхранение на сесии. Когато се отвори сесия, се задейства функция като fopen(), която заключва файла за четене и запис за други процеси. Решението да се промени хранилището на сесията, за да се премахне заключването, веднага се предлага, но ще говорим за това по-късно.

Подходи

1. Разделяне на операция на стъпки
   
2. Анкета на Ajax
   
3. Дълго гласуване
   
4. Рамка завинаги
   
5. Поточно предаване
   
6. Comet-сървър
   
7. Уеб-сокети

Нека разгледаме накратко всеки от тези подходи за решаване на проблема извършване на тежки операции и интерактивно уведомяване на потребителя за напредъка.

Разделяне на операция на стъпки

Първото нещо, което идва на ум, е да разделим операцията на стъпки. След завършване на следващата стъпка и изпращане на отговор до браузъра на потребителя, той сам започва следващата стъпка, като изпраща съответната Ajax заявка до сървъра.

В работещ проект този подходсе оказа не особено успешен поради факта, че тежките операции бяха практически неделими на стъпки. Освен това бяха използвани услуги на трети страни, работещи на сървъра, за работа с които беше необходимо да се създадат и подготвят съответните обекти по време на изпълнение на заявката. След изпълнение на заявката, която беше представена от 1 стъпка от операцията, обектите бяха „заковани“. Може би трябваше да помислим за повторното им използване, но не сме стигнали до това.

Анкета на Ajax

Следващото решение, което идва на ум, е да изпълните операция на сървъра и постоянно да запитвате сървъра за състоянието на протичащата операция, като изпращате поредица от Ajax заявки на определени интервали. На клиента можете да анализирате такъв сървърен отговор (например може да бъде JSON, съдържащ „съобщение“, „процент“, „грешка“ и „пренасочване“) и да нарисувате лента за напредъка, показваща състоянието на текущата операция.

Имаше опит да се използва подходът на анкета върху проект с два по различни начинизапазване на резултата от операцията:

Съхраняване на резултатите от изпълнението във файл – +.txt

Съхраняване на резултатите в базата данни, в съответната таблица – операции с_високо_тегло

Потребителят инициира операцията с помощта на ajax заявка, след което клиентският скрипт периодично анкетира сървъра и получава състоянието и напредъка на текущата операция - /operations/get_status/ .

Но се натъкнахме на следния проблем: продължителна операция стартира, но блокира файла на сесията, като по този начин елиминира възможността за изпълнение на паралелни заявки в рамките на една и съща сесия. С други думи, след стартиране на продължителна операция, всички заявки, запитващи сървъра, отидоха в опашка и изчакаха момента, в който основната заявка освободи файла на сесията.

Първото решение на проблема беше да се освободи файлът на сесията. За да направите това, PHP предоставя функция - session_write_close(), с който можете да затворите сесия за запис. Всъщност можете да стартирате операция, да прочетете данните от сесията, да направите промени в нея и да затворите сесията за запис.

Но в реалностите на проекта, като се вземе предвид установената архитектура, това решениенеуспешно прилагане. Записването на сесията беше необходимо на много места по време на продължителната операция. Освен това такова решение не може да се нарече „чисто“, т.к потребителят може да се наложи да „пътува“ из сайта или да изпълни друга тежка операция паралелно. Следователно беше необходима алтернатива.

Решението беше промяна на Session Storage, което гарантираше работа със сесията без блокиране при отваряне. Можете да изберете една от следните опции като ново хранилище за сесия:

• MySQL база данни;
• MongoDB;
• Memcached;

За да промените съхранението на сесии в PHP, има функция - session.save_handler(), което определя потребителски функциисъхранение на сесии. Те се използват за съхраняване и извличане на данни, свързани със сесия. Можете да намерите много примери за използването му в Интернет; вече има внедрени класове, които служат за прехвърляне на сесия към база данни или memcached.

Забележка: За да работи функцията, трябва да зададете опцията session.save_handlerпо смисъл потребителвъв вашия конфигурационен файл php.ini.

Проектът използва съхранение на сесии в mysql и mongodb като експеримент.

Забележка: Ако имате нужда параметърът, току-що написан в сесията, да бъде достъпен за други заявки, тогава сесията трябва да бъде „изчистена“ в mysql или mongodb, за да работи функцията за запис на сесия. За да направите това, трябва да го затворите за запис и да го отворите отново:

Публична функция session_flush() ( session_write_close(); session_start(); )

След внедряването на подходящите компоненти сесията вече не беше блокирана и позволи едновременното обработване на множество заявки, свързани с една и съща сесия. Сега не „губи“ ( заключване), какъвто беше случаят с файловете, при отваряне на файл с функцията fopen, освен това скоростта на сесията се увеличи значително.

Забележка: За употреба mongodbв PHP трябва да инсталирате mongodb като услуга, както и драйвер за работа в PHP.

Пример за инсталиране на CentOS :

1. Създайте хранилище

/etc/yum.repos.d/10gen.repo

1. Попълване със съдържание (в зависимост от битовата дълбочина на ОС)

име=10genRepository

baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64

1. Обадете се

1. Следваща

yum инсталирайте mongo-10gen mongo-10gen-сървър

1. Стартирайте „демона“

услуга mongod start

1. Инсталиране на драйвер

yum -y инсталирайте php-devel

sudo pecl инсталирайте mongo

разширение=mongo.so

След това можете безопасно да използвате mongodb.

Като пример прикачвам списък на CakePHP компонентите за прехвърляне на Session Storage и MongoDB

Mongo = нов Mongo($connection_string);<= 3) { $this->/* индекси */ $this->mongo->(self::MONGO_DATABASE)->(self::MONGO_COLLECTION)->ensureIndex("id", array("id" => 1));

$this->mongo->(self::MONGO_DATABASE)->(self::MONGO_COLLECTION)->ensureIndex("id", array("id" => 1, "expires" => 1)); // Регистрирайте този обект като манипулатор на сесия if ($this->forceSaveHandler) ( session_set_save_handler(array($this, "open"), array($this, "close"), array($this, "read"), array($this, "write"), array($this, "destroy"), array($this, "gc") ) $this->_timeout = Configure::read("Session.timeout") * 60;

Забележка) публична функция __destruct() ( опитайте ( $this->mongo->close(); session_write_close(); ) catch (Изключение $e) ( ) ) публична функция open() (връща true; ) публична функция close() ( $probability = mt_rand(1, 150); ($probability gc();) връща истина;

) публична функция read($id) ( $cursor = $this->mongo->(self::MONGO_DATABASE)->(self::MONGO_COLLECTION)->find(array("id" => $id)); ако ($cursor->count() == 1) ( $cursor->next(); ) else ( return false; ) $result = $cursor->current(); if (!empty($result) && isset() $result["data"])) ( return $result["data"]; ) ) публична функция write($id, $data) ( if (!$id) ( return false; ) $expires = time() + $this->_timeout; $session = array("id" => $id, "data" => $data, "expires" => $expires); $options = array("safe" => true, "fsync " => true,); $collection = $this->mongo->(self::MONGO_DATABASE)->(self::MONGO_COLLECTION); ->findOne($filter) == null) ( return $collection->insert (am(array("_id" => new MongoId($id)), $session), $options ) else ( return $collection ->update($filter, array("$set" => $session)) , am($options, array("upsert" => false)) ) ) публична функция destroy($id) (връща $this- >mongo->(self::MONGO_DATABASE)->(self::MONGO_COLLECTION)-> премахване (масив ("id" => $id), вярно);

Можете също така да добавите защита за броя на едновременните заявки в рамките на една сесия. В нашия проект това беше направено от отделен компонент, отговарящ за тежките операции като цяло - HighWeightedOperationsComponent.php, който проследяваше броя стартирани операции в рамките на една сесия и в зависимост от настройките позволяваше стартирането на строго определен брой операции.

Резултат:

Променено съхранение на сесии. Няма повече заключвания на сесии.

На клиента се инициира Ajax заявка за стартиране на операцията.

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

Създаден е компонент за управление на „тежки операции“.

Дълго гласуване

Подходът е подобен на предишния, но има съществена разлика: в първия случай клиентът сам проверява сървъра за промени, в същия случай се установява непрекъсната връзка със сървъра и самият сървър сигнализира за настъпването на промяна. Предимството на този подход е намаляване на трафика между клиента и сървъра.

Принцип: клиентският скрипт се свързва със сървъра и казва: „Ако имате данни, готов съм да ги взема веднага и след това ще се свържа отново.“ В някои сървърни реализации има буфериране, когато сървърът не изпраща незабавно данни, а чака: какво ще стане, ако сега се появи нещо друго, тогава ще изпратя всичко наведнъж. Но такова буфериране е вредно, тъй като въвежда забавяния, а ние искаме да постигнем максимална скорост! След като получи данните, браузърът трябва отново да отвори нова връзка. Продължителността на такава връзка може да се измери в часове, но това е на теория. Обикновено времето е много по-малко и максимумът достига 5 минути, след което просто се създава нова връзка. Това се прави, защото сървърите не харесват такива дълготрайни сесии, а самият HTTP протокол не е много подходящ за такава употреба.

Този подход не беше използван в проекта, но имаше дискусии.

Завинаги IFrame

Накратко: На страницата се създава скрит iFrame, който постепенно изобразява информация за напредъка на операцията или изпълнява java скриптове. Но за това HTTP сървърът и PHP трябва да бъдат конфигурирани така, че да могат да връщат данни на части по време на операцията. Това е обсъдено подробно в следващия параграф.

И така, ние инициираме операцията чрез iFrame елемент, скрит на страницата. На сървъра операцията издава повикването за данни на части и незабавно изпраща отговор на клиента, IFrame се опитва да изпълни изпратения отговор:

Поточно предаване

Подходът беше експериментално използван в проекта.

Възникна идея, какво ще стане, ако се опитаме да инициираме изпълнението на операция с ajax повикване и на сървъра да дадем (поточно) данни на клиентите част по част. Тогава може би на клиента всеки път, когато бъде получена следваща част от данните, ще се задейства някакво събитие, според което можем да актуализираме съответния блок и да покажем статуса на изпълнение.

Първо трябваше да намерим и приложим подходящите настройки за сървъра Apache и PHP, което доведе до търсене на информация в интернет и серия от тестове. В резултат на това настройките изглеждат така:

Публична функция подготви() ( // Изключете буферирането на изхода ini_set("output_buffering", "off"); // Изключете компресирането на изхода на PHP ini_set("zlib.output_compression", false); // Неявно изчистване на буфера(ите) ini_set("implicit_flush", true); ob_implicit_flush(true); // Изчистване и изключване на буферирането на изхода while (ob_get_level() > 0) ( // Вземете текущото ниво $level = ob_get_level(); // Край на буферирането ob_end_clean(); // Ако текущото ниво не се е променило, прекъснете if (ob_get_level() == $level) break; -gzip", "1"); apache_setenv("dont-vary", "1"); ) )

Написан е компонент, който напълно прилага този подход. Но след по-задълбочен анализ се оказа, че този подход е неприложим, т.к няма събития на клиента, сигнализиращи, че следващата част от данните е пристигнала от предварително изпратена ajax заявка. По събитие onSuccessДанните пристигат изцяло.

Комет сървър

Според Wikipedia Comet е всеки модел на уеб приложение, при което постоянна HTTP връзка позволява на уеб сървъра да изпраща данни към браузъра без допълнителна заявка от браузъра.

Общата характеристика на тези модели е, че всички те са базирани на технологии, поддържани директно от браузъра (например JavaScript), а не на патентовани добавки.

включено този проектимаше опит да се използва изпълнението на сървъра на Comet Dklab Realplexor .

Dklab Realplexorе Comet сървър, който ви позволява едновременно да поддържате стотици хиляди дълготрайни отворени HTTP връзки с потребителски браузъри. Кодът на JavaScript, изпълняван в браузъра, се абонира за един или повече канали на Realplexor и присвоява манипулатор за получаване на данни. Сървърът може да напише съобщение в един от тези канали по всяко време и то ще бъде незабавно предадено на всички абонати (поне един, поне хиляда), в реално време и с минимално натоварване на сървъра.

Уеб-сокети

Беше обсъдена и възможността за използване на WebSockets. Но ние изоставихме този подход поради „неподдържане“ на по-стари браузъри.

WebSocket е пълен дуплекс комуникационен протокол през TCP връзка, предназначен за обмен на съобщения между браузър и уеб сървър в реално време.

Резултат:

В резултат на това задачата беше изпълнена с помощта на подхода Polling, като сесиите бяха прехвърлени към MongoDB. Но последвалите дискусии, увеличаването на броя на „тежките“ задачи и тяхната сложност доведоха до използването на по-стандартно и надеждно решение - внедряване на опашка от изпълнени задачи с помощта на CRON Scheduler. Наистина, след като проверим всички права върху изпълняваната операция, можем да запазим нейния контекст в базата данни (таблица cron_taks), като преди това сме я сериализирали. На сървъра на определени интервали от време ще се стартира CRON shell, който ще вземе следващата задача от опашката, ще промени статуса й на IN_PROGRESS и ще я прехвърли към съответния манипулатор (TaskDispatcherComponent). Манипулаторът ще вземе десериализирания контекст на планираната задача и ще я изпълни в отделен процес. Всички модели и компоненти на системата са му достъпни. За да определите състоянието на изпълняваща се задача, можете да използвате подходите Polling и LongPolling, както и да организирате преглед на вашата опашка със задачи в отделен дисплей. Този подход се оказа по-надежден и разбираем, въпреки че изисква някои архитектурни промени в системата.

И така. Кодът на метода на всяка ws-операция се намира в модула за уеб услуга, към който принадлежи тази ws-операция. Модулът за уеб услуга се изпълнява само на сървъра.

Бележка 1: Няма смисъл да се пишат директиви за компилиране &На сървъра, &На Клиента и други.

За всяко извикване на уеб операция се създава отделна сесия с информационната база, така че всеки път, когато се извиква уеб операция, параметрите на сесията се инициализират. Инициализирането на параметрите на сесията се извършва в модула на сесията в процедурата "SettingSessionParameters".

Бележка 2: Не натоварвайте тази процедура с ненужни стъпки.

Лично аз съм за дадени на процедуратаПри първото извикване инициализирам само най-често използваните параметри на сесията. И само ако са необходими други параметри на сесията, при повторно извикване обработвам посочените параметри.

Процедура SettingSessionParameters(SessionParametersNames)

//същността на промените е да го получите веднага важни параметри, а ако имате нужда от повече параметри, използвайте подсистемата BSP

Ако SessionParameterNames=Undefined Тогава

Заявка = Нова заявка;

Заявка.Текст =

„ИЗБЕРЕТЕ ТОП 1

| ОТ

|Директория.Потребители КАТО Потребители

|КЪДЕ

|Users.IBUserIdentifier = &IBUserIdentifier";

IBUserIdentifier = InformationBase Users.CurrentUser().UniqueIdentifier;

Request.Parameters.Insert("IB UserIdentifier", IBUserIdentifier);

ResultUsers = Query.Run();

SelectDetailRecords = Query.Run().Select();

Докато SelectDetailRecords.Next() цикъл

SessionParameters.CurrentUser = SelectionDetailedRecords.Link;

EndCycle;

SessionParameters.CurrentAccount = SessionParameters.CurrentUser.Account;

В противен случай

StandardSubsystemsServer.SettingSessionParameters(SessionParametersNames);

endIf;

Край на процедурата

Ако прочетете статията 1C:Enterprise 8. Уеб услуги. Внедрявайки своя собствена уеб услуга, забелязахте, че в дървото на метаданните параметърът на операцията ws се нарича „Параметър“, а в метода, който го реализира, се нарича „Параметър“. Факт е, че името на операнда в метода на ws-operation не е от значение; Например, имаме операция Example1, в конфигуратора посочихме, че операцията има два параметъра „param1“ и „param2“ и създадохме процедура, която извежда „param2“.

Ако извикаме ws операцията Example1 и подадем param1=1, param2=2 като параметри, тогава резултатът ще бъде 2.

Но ако променим реда на операндите в конфигуратора:

Тогава същото обаждане ще върне 1.

Бележка 3: след като промените реда на параметрите на ws операция, не забравяйте да промените техния ред в заглавката на функцията, която изпълнява тази операция.

Бележка 4: Можете да използвате имена, различни от посочените в конфигуратора като операнди на операцията ws.

Ако някои от параметрите на ws операция имат отметка в квадратчето „Възможно празна стойност“, тогава този параметър може да не бъде посочен при извикване, но тук има няколко нюанса. Когато използвате клиент, например SoapClient, когато предавате параметър, не можете просто да вземете параметъра и изобщо да не го посочите. Например:

$a=$клиент->Plus2();

Този ред ще доведе до грешка "Неизвестна грешка. Няма достатъчно параметри на операцията." Тоест самият параметър трябва да бъде предаден, като се посочи нулевата стойност:

$zz=масив("Параметр"=>нула);

$a=$клиент->Plus2($zz);

Но тогава възниква въпросът как този празен параметър ще бъде прехвърлен на 1C. Логично е програмистът на 1C да иска да направи следното в метода на уеб работа:

Функция Plus2 (Параметър=0)

Параметър за връщане+2;

EndFunction

Тоест, посочете стойността на операнда, ако липсва.

Сега трябва да извикаме нашата уеб операция с празно. Ще дам пример за xml сапунено съобщение с нулева стойност.

xsi:nil="true" - показва, че този параметър няма стойност. За да можете да посочите null, трябва допълнително да свържете префикса xsi с пространството от имена:xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance".

Но ако той извика такава ws операция с празна стойност, той ще получи съобщение за грешка:

Сапун: Клиент

Неизвестна грешка.

поради:

(WebService.WebService.Module(2)): Не може да се извърши преобразуване на стойност към тип Number

поради:

(WebService.WebService.Module(2)): Не може да се извърши преобразуване на стойност към тип Number

Това е така, защото предадената нулева стойност се преобразува в стойността 1c - „Недефинирано“. Можете да проверите това, ако пренапишете процедурата по този начин.

Функция Plus2 (Параметър=0)

Ако параметър = недефиниран тогава

Резултат = 1;

В противен случай

Резултат = 2;

endIf;

Връщане на резултат;

EndFunction

Резултатът ще бъде - 1.

Бележка 5:няма смисъл да се записва стойността по подразбиране на операнда на операцията ws(Функция Plus2 (Параметър=0)). За операнди, които могат да приемат празна стойност, трябва да добавите проверка за равенство „Недефинирано“.

Бележка 6:При предаване на параметър тип низ към уеб операция, низ от един или повече интервали се съкращава до празен низ.

Бележка 7:При предаване на параметър тип datetime към уеб операция, използваща формат, указващ часовата зона, времето се преобразува в часовата зона, в която се намира платформата 1c. Например, ако дадена операция има параметър „Дата“ от тип datetime, компютърът, на който се намира 1c, е в +6 часова зона, тогава при предаване на стойността „2012-09-14T00:00:00.000+02:00 ” към този параметър в кода на уеб операцията този параметър ще има стойност „09/14/2012 4:00:00”. Следователно "+02:00" показва в коя зона е подателят. Това ще ви позволи да не мислите за промяна на времето, когато работите в няколко часови зони.

Можете да прочетете малко повече за уеб услугите, тяхното внедряване, тестване и т.н. тук.

Днес WEB услугите се използват почти навсякъде - те ни предоставят информация за самолетни и влакови полети, валутни курсове и време. Не е изненадващо, че 1C също има способността да създава свои собствени WEB услуги, което му позволява да действа както като доставчик, така и като потребител. Този механизъм е вграден в платформата 1C:Enterprise 8.3 и разработчиците дори могат да добавят типична конфигурациясобствени обекти от типа “WEB услуги”. Тяхната архитектура е изградена върху набор от услуги, които ви позволяват да обменяте информация с друг софтуер.

Създаване на уеб услуга 1C

Едно от основните предимства на 1C WEB услугите е липсата на необходимост от предоставяне на директен достъп до данните за информационна сигурност. Правилно конфигурираната уеб услуга 1C позволява на други приложения да използват функции отвън. В такива случаи самата функция трябва да определи правото за използване на данни според зададените параметри съгласно правилата, предписани от разработчика.

Как да създадете уеб услуга в 1C?

За да може определена функция на системата 1C да стане достъпна за външен софтуер, е необходимо да изпълните следния алгоритъм от действия:

1. Отидете на конфигурацията и добавете обект на WEB услуга в определен клон на дървото;
2. Опишете всички операции, които нашата функционалност може да изпълнява. Описанието на функциите се извършва в модула на вградения език 1C;
3. Добавете описание на параметрите на функциите на уеб услугата. Моля, обърнете внимание, че типовете данни са описани, като се вземат предвид съществуващите типове на механизма XDTO, въведен в платформата версия 8.1;
4. Публикувайте създадената WEB услуга на сървъра. Механизмът, вграден в платформата 1C, поддържа следните стандарти:

• SSL/TLS
• WS-I BP

Пример за създаване на проста WEB услуга

За да демонстрираме най-ясно работата на механизма на WEB услугите, нека създадем пример – функционалност, която определя дължината на въведения низ. Софтуерще предаде низ като параметър на заявката, а функцията, описана в 1C, ще върне броя знаци. Когато създавате, трябва да запомните, че публикуването на този механизъм ще даде възможност на различен софтуер да има достъп до него. Тъй като не всеки софтуер може да приеме кирилицата, ние ще именуваме конфигурационните обекти с латински букви.

Отворете конфигуратора, намерете клона „WEB услуги“ в дървото и добавете нова услуга"wa_LengthString". Трябва също да добавите нова операция в раздела „Операции“. Нека го наречем “CalcLengthString”, посочете типа на връщаната стойност в свойствата - int или integer и създайте параметъра “InputString” вътре в него. Оставяме типа стойност като низ.

Сега трябва да регистрирате действието на функцията CalcLengthString в модула за WEB услуги. За да направите това, отворете свойствата на създадената функция и щракнете върху бутона под формата на лупа вдясно, до полето за въвеждане „Име на процедурата“. 1C автоматично ще създаде функция в нашия WEB сервизен модул и ще я отвори, за да можем да опишем действието CalcLengthString. Нека се възползваме от това и напишем действието на функцията – определяне на дължината на входния низ.

Всъщност това завършва създаването на проста WEB услуга. Сега трябва да „публикувате“ тази услуга в общ достъптака че софтуерът на трети страни или други 1C системи да могат да използват тази функционалност.

За да можем да публикуваме създадената уеб услуга с нейната функционалност е необходимо да имаме достъп до сайта. Преди да започнем да публикуваме услугата, трябва да проверим името на файла в свойствата на създадения модул wa_LengthString. Трябва да е ясно, просто и да има разширение „1cws“.

Сега е време да публикуваме WEB услугата, която създадохме на сървъра. Тази функция се появи във версия на платформата 8.3 и много компании вече са осъзнали пълните предимства на тази функционалност. За да започнете да публикувате, трябва да отворите формата “Администриране/Публикуване на уеб сървър...” в конфигуратора.

В прозореца, който се отваря, трябва да конфигурираме 1C уеб услугите и да попълним определени полета:

• Име. Определя папката на уеб сървъра, в която ще се съхранява описанието на нашата уеб услуга. Бъдете внимателни с главните букви, тъй като понякога сървърите правят разлика между големи и малки букви;
• Уеб сървър. Трябва да изберете сървър от инсталираните на вашия компютър;
• Каталог. Трябва да изберете пътя до папката, където се съхраняват данните на уеб сървъра за настройка на връзката. Използват се само латински букви;
• Два знака от булев тип. Първият ще ни бъде полезен, ако трябва да конфигурираме достъп до конфигурацията чрез уеб клиент. За да публикувате услуга 1C, трябва да поставите отметка във второто квадратче.

Остава само да проверите дали желаната WEB услуга има отметка в първата колона и да кликнете върху „Публикуване“.

Тъй като този механизъм все още е съвсем нов, може да срещнете грешка като „Възникна грешка при извършване на файлова операция...“. В този случай просто трябва да кликнете отново върху „Публикуване“. В повечето случаи това ще помогне и ще видите съобщение, указващо, че уеб услугата е публикувана.

<имяСервера>.ru/<ИмяУказанногоКаталогаНаСервере>/ws/<НаименованиеФайла>.1cws?wsdl

В отговор на такава заявка за адрес браузърът трябва да покаже структурата на XML файла. Ако видите празна страница, грешка или странни символи(проблеми с кодирането), тогава трябва да проверите всички стъпки отново. Също така е добра идея да се уверите, че сървърът е конфигуриран правилно и имате достъп до него. След успешно публикуване услугата 1C WEB ще може да се използва от приложения на трети страни.

Уеб услугата е инструмент за интеграция, който предоставя концепцията за архитектура на услугата. Тоест системата 1C може да бъде представена като набор от независими услуги за системи на трети страни и от своя страна може да действа като потребител на такива услуги. Архитектурна диаграма:

Мениджърът на уеб услугата, представен на диаграмата, изпълнява следните задачи:

• управлява набор от връзки към информационни бази
• поддържа описание на услугата във формат WSDL (език за описание на уеб услуги, език за описание на уеб услуги, базиран на XML)
• внедрява протокола SOAP (Simple Object Access Protocol), осигурява сериализиране на съобщения, извикване на необходимите уеб услуги

В конфигурацията уеб услугите се изпълняват като споделени обекти:

За уеб услуга се определя набор от операции, всяка от които може да се характеризира с определени параметри за пренос на данни:

Уеб услугата работи с помощта на XML, така че трябва да посочи схема за маркиране; За да направите това, уеб услугата препраща към пакета XDTO:

Въпрос 08.42 от изпита 1C: Platform Professional. Мениджърът на WEB услуги решава проблема:

1. управление на набор от връзки към информационни бази
2. поддръжка за описание на услугата WSDL, внедряване на протокола SOAP
3. Поддръжка на WEB приложения
4. верни отговори 1,2
5. верни отговори 2,3
6. верни отговори 1,2,3

Правилният отговор е четвъртият, уеб услугата не осигурява работата на уеб приложението (вижте неговите функции по-горе).

Въпрос 08.43 от изпита 1C: Platform Professional. Конфигурационният обект "WEB услуга" се използва за:

1. организиране на достъп до уеб услуги чрез статична връзка
2. функционалност за експортиране на това информационна база

Правилният отговор е третият - уеб услугата определя някои функции, които могат да бъдат достъпни извън тази база данни.

Въпрос 08.44 от изпита 1C: Platform Professional. Конфигурационният обект "WSLink" се използва за:

1. организиране на динамичен достъп до уеб услуги
2. организиране на достъп до уеб услуги чрез статична връзка
3. експортиране на функционалността на тази информационна база

Правилният отговор е вторият. WS връзката е споделен конфигурационен обект, предназначен за достъп до уеб услуги на трети страни чрез статична връзка. Връзката се състои от модел на данни, по същество пакет XDTO, и уеб услуга, от която се публикува връзката:

Въпрос 08.45 от изпита 1C: Platform Professional. Ако функцията, която изпълнява операцията на WEB услугата, върне стойност. Тогава такава стойност се дефинира (при настройка на съответния конфигурационен обект) като имаща типа:

1. Линия
2. Номер
3. Булева стойност
4. XML елемент
5. XDTO обект или стойност
6. верни отговори 1,2,3

Верният отговор е пети.

Въпрос 08.48 от изпита 1C: Platform Professional. Ако функцията, която изпълнява операцията на WEB услугата, приема произволна стойност като параметър. Тогава такава стойност се дефинира (при настройка на съответния конфигурационен обект) като имаща типа:

1. Линия
2. Номер
3. Булева стойност
4. XML елемент
5. XDTO обект или стойност
6. верни отговори 1,2,3

Верният отговор е същият като номер пет.

Въпрос 08.46 от изпита 1C: Platform Professional. При достъп до WEB услуга чрез статична връзка последователността от действия е следната:

1. получаване на wsdl описание, настройка на връзка (създаване на прокси), достъп до операция на услугата
2. настройка на връзка (създаване на прокси), достъп до услуга
3. извикване на сервизна операция

Верният отговор е вторият - в случай на статичен линк не е необходимо всеки път да получавате wsdl описание.

Въпрос 08.47 от изпита 1C: Platform Professional. При достъп до WEB услуга чрез динамична връзка последователността от действия е следната:

1. получаване на wsdl описание, настройка на връзка (създаване на прокси), достъп до операция на услугата
2. настройка на връзка (създаване на прокси), достъп до услуга
3. извикване на сервизна операция

Правилният отговор е първият.

Печат (Ctrl+P)

Уеб услуги

Механизмът за уеб услуги ви позволява да използвате 1C:Enterprise като набор от услуги в сложни разпределени и разнородни системи, а също така ви позволява да интегрирате 1C:Enterprise с други индустриални системиизползване на ориентирана към услугата архитектура.

Добавяне на уеб услуга

За да добавите уеб услуга към конфигурационното дърво, изберете клона Общи – Уеб услугии изпълнете командата контекстно менюдобавете
В резултат на изпълнение на командата ще се отвори прозорецът за редактиране на уеб услугата.

В раздела Други на прозореца за редактиране на уеб услуга задайте следните параметри:
● URI на пространството от имена– съдържа URI на пространството от имена на уеб услугата. Всяка уеб услуга може да бъде уникално идентифицирана чрез своето име и URI на пространството от имена, към което принадлежи.
● XDTO пакети – списък с XDTO пакети, чиито типове могат да се използват като типове връщане на операции и типове параметри на операции на уеб услуга.
● Име на файла на публикацията– името на файла с описание на уеб услугата, който се намира на уеб сървъра.
За да получите достъп до уеб услугата, трябва да използвате адрес, който се формира по следния начин: <Имя хоста веб-сервера>/<Имя виртуального каталога>/ws/<Имя Web-сервиса> или <Имя хоста веб-сервера>/<Имя виртуального каталога>/ws/<Адрес Web-сервиса> .
Така че, ако виртуалната директория има името DemoWS, името на уеб услугата в конфигуратора се посочва като Демонстрация на WorkWS,и DemoWorkWS е посочен като адрес, тогава уеб услугата може да бъде достъпна едновременно на два адреса (за получаване на достъп от локалната машина):
http://localhost/DemoWS/ws/Демонстрация на WSили http://localhost/DemoWS/ws/DemoWorkWS.
В допълнение, разделът съдържа бутон Module, който ви позволява да отворите модула на уеб услугата за редактиране.

Йерархична структура на уеб услуга

Всяка уеб услуга, описана в конфигурационното дърво, може да съдържа набор от операции. Всяка операция трябва да съответства на експортирана процедура, описана в модула за уеб услуга.

Описание на уеб услугата

От своя страна всяка операция може да съдържа набор от параметри, имената на които трябва да съответстват на имената на параметрите на процедурата, която описва тази операция.

Операции на уеб услугата

В раздела Операции добавяте операция за уеб услуга. Редактирането на свойствата на дадена операция се извършва в палитрата със свойства.

Свойства на операцията на уеб услугата

Тип връщане– типът стойност, която операцията на уеб услугата връща. Може да бъде тип стойност XDTO или тип обект XDTO.
Възможна празна стойност– показва дали върнатата стойност може да бъде нула.
В транзакция – показва дали кодът на модула за уеб услуга ще бъде изпълнен в транзакция или не. Ако свойството е зададено, тогава, когато се извика уеб услугата, автоматично ще започне транзакция и когато бъде завършена, транзакцията или ще бъде ангажирана, или транзакцията ще бъде върната назад (в зависимост от резултатите от изпълнението). Ако свойството не е зададено, няма да се стартира транзакция, когато модулът за уеб услуга започне да се изпълнява.
Име на процедура – ​​името на процедурата за експортиране на модула на уеб услугата, която ще бъде изпълнена при извикване на това свойство.
Режим на контрол на заключването на данни– указва кои ключалки ще се използват при достъп до данни.

Параметри на работа

В раздела Операции за посочената операция трябва да зададете параметрите на операцията на уеб услугата. Редактиране на свойствата на параметрите
изпълнява се в палитрата със свойства.

Свойства на параметрите на операцията

Тип стойност—тип стойност на параметъра за работа на уеб услугата. Може да бъде тип стойност XDTO или тип обект XDTO.
Възможна празна стойност– показва дали стойността на параметъра на операцията може да приеме недефинирана стойност.
Посока на предаване– определя посоката на използване на предаване на данни този параметър. Възможни стойности:
● Вход – означава, че параметърът може да се използва само за предаване на данни към уеб услугата.
● Изход – означава, че параметърът може да се използва само за получаване на данни от уеб услугата.
● Вход – Изход– означава, че параметърът може да се използва както за предаване на данни, така и за получаването им от уеб услугата.

Указване на дефинирани от системата типове

За да използвате типовете, дефинирани от системата 1C:Enterprise в уеб услуга (например в параметрите и връщаната стойност на операциите), трябва да дефинирате XDTO пакети в конфигурацията и за всеки пакет да посочите в неговия списък с импортирани пакети (свойство Директиви за импортиране) набор от пакети на платформа, в които са включени тези типове. URI на пространството от имена за указване на типа се съдържа в помощната статия за синтаксиса за обект от този тип.

Публикуване на уеб услуги

Задачата за публикуване се свежда до поставяне на файла за публикация в подходящата директория. За да публикувате, трябва да изпълните командата от менюто „ Администриране – Публикуване на уеб сървър…“.

В резултат на изпълнение на тази команда ще се отвори прозорец, в който информационната база се публикува на локалния компютър.

внимание!Извършването на операцията изисква права на администратор (за Windows OS) или права на суперпотребител (за Linux OS) на компютъра, на който се извършва публикацията

Основни настройки за публикуване

на „ Основен” показва данните, необходими за завършване на публикацията.

Ако публикацията не е извършена преди, стойностите на полето (настройките) се попълват със стойности по подразбиране (името се избира от името на информационната база). Променете тези настройки, ако е необходимо.
Ако публикуването вече е извършено, тогава настройките се избират според предварително зададените.
Ако системата при отваряне на диалогов прозорец с текущите настройки намери публикация, но нейните данни се различават от данните за настройките, се издава заявка за промяна на настройките.
Ако публикацията на настройките не бъде намерена, се издава предупреждение.

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

Името на публикацията трябва да отговаря на правилата за URL (стандарт RFC 1738).
Ако уеб сървърът е Apache 2.2 или Apache 2.4, тогава трябва да се използват американски ASCII знаци за името на директорията.

Забележка.Когато използвате уеб сървъра Apache, и двете версии на уеб сървъра са достъпни за избор в диалоговия прозорец за настройки. Моля, обърнете внимание, че настройките за публикуване за Apache 2.2 и Apache 2.4 са несъвместими една с друга. Следователно е необходимо да изберете правилно версията на уеб сървъра в диалоговия прозорец.

Посочете необходимостта от публикуване тънък клиенти уеб клиент, както и уеб и HTTP услуги.

Ако квадратчето за отметка „ Публикувайте стандартен ODATA интерфейс” е инсталирана, услугата ODATA ще бъде публикувана, която ви позволява да четете и променяте данни от информационната база чрез HTTP заявки.

на „ Уеб услуги"проверете квадратчето" Публикуване на уеб услуги” и създайте списък в таблицата, като поставите отметки в квадратчетата за тези уеб услуги, които искате да публикувате.

Ако квадратчето за отметка „Публикуване на уеб услуги по подразбиране“е инсталиран, тогава при актуализиране на публикацията избраните уеб услуги ще бъдат публикувани автоматично. В противен случай уеб услугите ще бъдат маркирани като непубликувани.

Ако квадратчето за отметка „Публикуване на уеб услуги за разширения по подразбиране“инсталиран, тогава при актуализиране на публикацията уеб услугите, добавени от разширения, ще бъдат публикувани автоматично.