Интерес к интернет-технологиям с каждым годом становится все больше и больше. Эта тенденция не обходит стороной и такие информационные системы как 1С. Для удаленного взаимодействия (через интернет) в 1С 8 предусмотрен ряд объектов, таких как HTTP соединение и веб-сервисы. Но традиционно не многие 1С-разработчики сильны в вопросе веб-технологий. А когда возникает потребность в более детальном их изучении, то многим знакома ситуация, когда не знаешь, с чего же начать. И информации в интернете вроде бы много, но как разобраться в этом разнообразии, как выделить главное?
В этой статье я постараюсь выделить это «главное», которое поможет сориентироваться и заложить основу для дальнейшего, более углубленного изучения современных интернет-технологий. Буквально тезисно пройдемся по основным направлениям, рассмотрим всем известные (кому-то понятные, кому-то нет) термины «PHP», «JavaScript», «AJAX» и др.
1. Интернет, сервер, браузер
С понятием интернета, думаю, знакомы все и все представляют, что это такое. Если говорить коротко, то интернет — это единая сеть, объединяющая множество компьютеров в единое информационное пространство, в котором каждый компьютер имеет свой уникальный адрес. С помощью этого адреса компьютеры находят друг друга и обмениваются информацией.
Компьютеры можно поделить на две категории: сервера и клиенты. Под сервером обыватели понимают некий центральный компьютер, стоящий в офисе и хранящий на своем жестком диске в сетевой папке рабочие файлы. Это грубое представление отчасти верное, но не полное.
Сервер — это еще и программное обеспечение, которое стоит на компьютере и которое позволяет обрабатывать запросы других компьютеров, находящихся далеко за пределами офиса, а также отвечать им. Такое взаимодействие происходит по определенным правилам, протоколам (например HTTP, самый распространенный протокол интернета, речь о котором пойдет ниже). Если вы раньше когда-либо слышали такие слова как IIS или Apache, то это как раз и есть то самое ПО сервера (как правило его называют веб-сервером), которое отвечает за обработку запросов и отправку ответов.
Клиент — это компьютер, инициирующий запрос серверу. Но не только компьютер, а также как и в случае с сервером еще и программное обеспечение. Самый яркий пример — это веб-браузер (Internet Explorer, FireFox, Chrome, Safari и др.). Давайте далее для простоты так и будем под клиентом понимать веб-браузер, хотя на самом деле это может быть любое приложение, устанавливающее соединение и взаимодействующее с сервером.
Теперь разберемся непосредственно с процессом взаимодействия клиента и сервера. Что запрашивает клиент у сервера? Для более правильной терминологии будем говорить, что клиент запрашивает ресурс. По сути любой ресурс — это файл, хранящийся на сервере, только в зависимости от типа файла ответ сервера может быть самый разный. Яркий пример простого запроса — это когда пользователь в адресной строке браузера набирает адрес ресурса и нажимает Enter (например www.yandex.ru). По этому адресу браузер отыскивает в интернете компьютер и отправляет его веб-серверу запрос на получение главного файла (имя файла писать не обязательно, обычно веб-сервер знает, какой файл по данному адресу является главным). Сервер принимает запрос, обрабатывает и отправляет браузеру обратно считанную из главного файла информацию (как правило это поток html, о котором речь пойдет ниже). Браузер принимает информацию, обрабатывает html-код и рисует в своем окне красивую страничку, которую видит пользователь.
В процессе навигации по страничке пользователь может щелкнуть мышкой по какой-нибудь ссылке, которая указывает на другой ресурс и взаимодействие клиента и сервера повторяется, что приводит к перезагрузке и обновлению страницы новыми данными, полученными с сервера. Схематично взаимодействие клиента и сервера представлено на картинке ниже.
2. HTTP и HTML
Как уже было сказано ранее, общение клиента и сервера происходит по определенным правилам (протоколам). Самым распространенным из которых является HTTP, что означает протокол передачи гипертекста. Он описывает структуру запроса клиента и ответа сервера. Ниже на рисунке хорошо видно, из чего состоит такая структура.
Как видим общение клиента и сервера фактически сводится к обмену самой обычной текстовой информацией, которую может прочитать человек (см. тело запроса и ответа). Первая строчка запроса — это непосредственно команда веб-серверу от браузера получить таким-то методом такой-то ресурс по такому-то протоколу. Основные методы получения ресурсов — это GET и POST. В теории GET-метод служит для чтения ресурса, а POST — для изменения данных ресурса, но технически у метода GET нет запрета на изменение. На запрос сервер отвечает браузеру кодом ответа (в нашем случае 200 означает, что ресурс найден и отдан, т.е. ОК). В заголовках содержится служебная информация. Набор заголовков определяется конкретными условиями общения клиента и сервера. В теле ответа содержится непосредственно данные, ради которых все взаимодействие и затевалось.
При общении пользователя с внешним миром через браузер тело ответа как правило содержит поток HTML-кода. HTML — это язык гипертекстовой разметки, который понимает браузер. Прочитав этот код браузер отрисует пользователю страничку на экране. Но, как можно догадаться, ничто не мешает в теле ответа передать другие данные, например xml или обычный текст. Так в принципе и поступают в ряде случаев, когда нужно организовать удаленное взаимодействие между системами, только в этом случае клиентом будет выступать не браузер, а непосредственно одна из удаленных систем.
3. PHP и MySQL
Теперь мы знаем, что ресурс — это конкретный файл, обратившись к которому по протоколу HTTP клиент получит в ответ от веб-сервера содержимое этого файла. Но с увеличением объема хранимой информации встает вопрос о правильной организации ее хранения. Очевидно, что хранить всю информацию в одном или нескольких больших файлах — не вариант. Также не вариант, когда информация разбита на множество очень мелких файлов. Вот тут сильно помогают базы данных. Одна из самых распространенных баз данных для хранения серверной информации — это MySQL. С ее помощью обеспечивается безопасное хранение, извлечение и администрирование информации.
А для того, чтобы веб-сервер мог извлекать из базы и правильно отдавать информацию клиенту существуют серверные языки программирования, ярким представителем которых является PHP. Конечно же, серверный язык может не только извлекать и отдавать — у него есть еще очень много полезных функций, но для простоты понимания будем считать именно так. Код PHP вставляется прямо в тело ресурса и когда веб-сервер читает содержимое ресурса, чтобы отдать его клиенту, этот код выполняется (извлекается информация из базы, производятся какие-то вычисления и т.п.). Результатом выполнения является динамически скомпонованный все тот же html-код, который и направляется клиенту.
4. JavaScript, AJAX и Web 2.0
Получив данные браузер отрисует их пользователю. Единожды отрисованная информация статична. Каждая новая порция информация требует обращения к серверу и перезагрузки страницы браузера. Для повышения интерактивности (выпадающие списки, плавающие формы и др.) без обращения к серверу придуман специальный клиентский язык, встроенный во все браузеры, JavaScript. Его используют для манипуляции полученными с сервера данными. В то время как PHP является серверным языком, JavaScript существует только на клиентской части. Исполняемые JavaScript конструкции называют сценариями. Они встраиваются в html-код и загружаются с ресурса на сервере, но исполняются на клиенте, т.е. после того, как данные получены и загружены браузером.
Помимо манипуляции данными JavaScript обладает такой замечательной функциональностью, как взаимодействие с сервером без перезагрузки страниц браузера. Подобная технология значительно сокращает объем передаваемых данных, ведь нет необходимости перезагружать страницу целиком — достаточно получить необходимые данные и разместить их в нужном месте страницы. Такая методика называется AJAX, что переводится как асинхронный JavaScript и XML. Слово «асинхронный» означает, что ответ сервера может приходить в фоновом режиме, т.е. послав запрос браузеру не нужно блокировать работу пользователя до получения ответа — он может продолжить работу, а когда придет ответ, браузер его увидит и обработает. На рисунке ниже схематично приведено сравнение двух моделей взаимодействия клиента с сервером: традиционной и с применением AJAX.
На этой схеме видно, что в отличие от традиционной модели, в модели AJAX веб-ресурс загружается один раз, а дальше по мере необходимости подгружаются только необходимые данные, обработка и вставка в html-код страницы которых производится уже на клиенте (в браузере).
Если раньше ресурсы интернета рассматривались в основном как средство получения информации, то с развитием технологии AJAX появилась возможность интерактивного манипулирования ими, что выводит клиент-серверное взаимодействие на качественно новый уровень, понимаемый под термином Web 2.0. Ресурсы, созданные на базе технологий Web 2.0, отличает повышенная интерактивность. Фактически, такие ресурсы вполне могут заменить десктопные приложения. За примерами далеко ходить не надо. Интернет-сервис Google Docs предоставляет функциональность, схожую с основными приложениями пакета Microsoft Office с той лишь разницей, что никаких программ на компьютер устанавливать не нужно — вся работа осуществляется в окне браузера.
Говоря о JavaScript, стоит отметить тот факт, что в нем достаточно жестко реализуется политика безопасности — так называемая Same Origin Policy, суть которой сводится к простому правилу — действие JavaScript распространяется на данные, загруженные с одного домена (адреса) при прочих равных. Таким образом, например, если сценарий, загруженный с ресурса www.site1.com попытается напрямую из клиентской части обратиться к ресурсу www.site2.com, то получит запрет. Конечно существуют методики обхода такого ограничения. Скажу больше, современные версии JavaScript позволяют делать запросы на ресурсы на других адресах, но в этом случае запрос должен содержать специфические атрибуты (заголовки), а веб-сервер должен быть специальным образом настроен на прием таких запросов. Методика такой настройки называется CORS (cross-origin resource sharing) и у нее есть своя официальная спецификация. Однако не всегда есть возможность настроить веб-сервер под свои нужды, поэтому, если вы на практике столкнетесь, например, с потребностью получить данные по технологии AJAX с другого ресурса — проксируйте такие запросы через сервер, ведь серверная часть лишена подобных ограничений. Т.е. из клиентской части отправляете AJAX запрос своему веб-серверу, тот в свою очередь с помощью того же PHP перенаправляет запрос на нужный ресурс, получает данные и возвращает клиенту.
5. RPC, SOAP и веб-сервисы
От теоретических выкладок постепенно подошли к более практическим вопросам. RPC (remote procedure call) переводится как вызов удаленных процедур. Это класс технологий, позволяющих информационным системам удаленно взаимодействовать друг с другом. Таких технологий много и протоколы передачи данных они используют разные. Остановимся на рассмотрении SOAP (simple object access protocol), как более практичной с точки зрения 1с, т.к. именно на ней базируются веб-сервисы 1с (кстати говоря не только 1с).
Способом передачи (транспортом) данных по протоколу SOAP является, как правило, старый добрый HTTP, о котором говорилось выше. В тело HTTP-сообщения помещаются данные в виде XML-текста, сформированного по определенным правилам (спецификации протокола SOAP). Тело запроса содержит XML-текст команды и параметры вызова метода в удаленной информационной системе, а тело ответа содержит XML-текст возвращаемых этим методом данных. По тем же правилам спецификации на стороне сервера или клиента XML-содержимое SOAP-сообщения интерпретируется в конкретные параметры или объекты. Возникает резонный вопрос, раз SOAP — это обмен при помощи XML, то зачем нужен именно специальным образом сформированный XML? Почему бы не передавать обычный XML с теми же данными? Все просто. При получении XML его придется разбирать (парсить) при помощи трехэтажного программного кода, так как заранее неизвестно, что это за XML и какая у него структура. Протокол же SOAP позволяет заранее определить структуру передаваемых данных а также опубликовать методы информационных систем, доступные для удаленных вызовов, что избавляет разработчиков от сложных процедур вызова методов и разбора данных.
Именно по таким принципам работают SOAP веб-сервисы. Если коротко, то их суть заключается в следующем. В удаленной информационной среде разворачивается веб-сервис, который публикуется на веб-сервере. Это означает, что у веб-сервиса появляется собственный адрес и с этого момента его можно называть ресурсом. Внутри среды между ее методом (функцией, процедурой) настраивается связь с данным веб-сервисом. Если с клиента по протоколу HTTP послать запрос на этот адрес, то веб-сервер, приняв этот запрос, транслирует его непосредственно в информационную среду, переведя входные параметры в удобный для нее формат. В информационной среде срабатывает связанный с веб-сервисом метод, отрабатывает и возвращает результат обработки обратно веб-серверу, который в свою очередь возвращает его клиенту по тому же протоколу HTTP.
6. 1С: веб-сервисы и HTTPСоединение
Итак, мы рассмотрели основы технологий, на которых базируется удаленное взаимодействие между информационными системами (файловый обмен и обмен почтовыми сообщениями принципиально не рассматривались). Какие же из них используются в 1С?
Прежде всего надо отметить, что начиная с платформы 1С 8.1 появились SOAP веб-сервисы, которые в значительной степени повысили функциональность системы. Их, наряду с веб-расширением, вполне можно рассматривать в качестве основы для создания веб-интерфейсов к 1С. В этой связи есть интересная статья «Примеры использования web сервисов 1С из браузера», в которой детально рассматривается применение технологии AJAX и веб-сервисов для построения веб-интерфейса для 1С. И пусть вас не смущает, что в платформе 8.2 появилась возможность работать с 1С из браузера и может показаться, что данная тематика неактуальна. Уверяю вас — это далеко не так. Управляемый интерфейс 8.2 очень сильно шаблонизирован и повлиять на него разработчик практически никак не может. Чтобы делать действительно красивые, функциональные и юзабилити-мощные интерфейсы придется пользоваться описанными технологиями.
Веб-сервисы также можно использовать для обмена между двумя базами. Можно обмениваться произвольными XML-сообщениями, что повышает безопасность такого взаимодействия, в отличие от применения обмена, основанного на выгрузке/загрузке файлов, когда файл по пути могут подменить. Так, например, можно осуществлять выгрузку проводок из зарплатной базы в бухгалтерскую, расходных накладных из торговой конфигурации в бухгалтерскую и т.п.
Если веб-сервисы — это надстройка к протоколу HTTP посредством протокола SOAP, то объект HTTPСоединение позволяет делать прямые запросы и получать ответ от веб-сервера напрямую по протоколу HTTP. Примером может служить выгрузка каталога товаров в интернет-магазин. При помощи HTTPСоединение отправляем POST-запрос с данными о товарах (например в виде XML, включенного в тело запроса) на известный нам адрес (это может быть определенная нами .php страничка). На стороне веб-сервера, на котором находится интернет-магазин, кодом PHP разбираем полученный XML и складываем данные о товарах в базу данных (MySQL например). Подобная техника отлично описана в статье «Передача файлов и данных на веб-сервер средствами 1С:Предприятие 8.1 методом POST» — рекомендую к прочтению.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Интерес к интернет-технологиям с каждым годом становится все больше и больше. Эта тенденция не обходит стороной и такие информационные системы как 1С. Для удаленного взаимодействия (через интернет) в 1С 8 предусмотрен ряд объектов, таких как HTTP соединение и веб-сервисы. Но традиционно не все 1С-разработчики сильны в вопросе веб-технологий. А когда возникает потребность в более детальном их изучении, то многим знакома ситуация, когда не знаешь, с чего же начать. И информации в интернете вроде бы много, но как разобраться в этом разнообразии, как выделить главное?
Перейти к публикации
Хорошая вроде статья, а уже за что-то минус влепили, и без объяснения
хорошая теория, я бы сказал… не более… а вот практика (годовалой давности) —
(3) с теории все начинается, в т.ч. и практика… в школу-то все ходили
(3) на мой взгляд вот это куда более практичней
Автор молодец.
Теория хорошая. Ясно, кратко, понятно!!!
Это база. Дальше вглубь. Он это явно и сказал.
— и на эту же ссылку он потом так же сослался и рекомендовал ее.
А минусы ставят это кто считает себя «сильно умными и всезнающими» и зачастую в пратике все наоборот.
Действительно, коротко и понятно. Мне статья очень понравилась.
Парочка очепяток:
1. раздел 4. JavaScript, AJAX и Web 2.0, в начале второго абзаца:
2. раздел 5. RPC, SOAP и веб-сервисы, первый абзац:
(7) спасибо, поправил
Все бы было хорошо, пока не начинаешь читать откровенный бред параграфа №6. И тут даже типичность обмена xml от soap сервиса отходит на второй план.
1. С каких пор web сервисы в 1С повышали масштабируемость системы?
2. Какого черта сравнивать систему для удаленной работы людей (web формы 1С) и систему удаленного взаимодействия приложений (web сервисы)?
3. Если файлы можно подменить, то почему нельзя подменить запросы?
4. Зачем в локальной сети городить огород из веб сервера, для обмена между базами (можно осуществлять выгрузку проводок из зарплатной базы в бухгалтерскую)?
5. Кто сказал, что управляемые формы не настраиваются? Может надо просто уметь их настраивать?
Но последний абзац — это абзац полный. На кой ляд городить огород протоколов, что бы избы без гвоздей топором строить? В 1С есть и гвозди и молотки (ws-ссылки и xdto).
А так картинки прикольные.
Да, картинки, прикольные, — вот только ajax в контексте чего? в контексте ликбеза? просто привлек заголовок …
(9) Да, не, последний абзац, — упоминание единственного http-шного клиента 1С — http соединение…
(14) Статья обо всем и ни о чем. Как вводная для программиста-новичка 1С покатит. По крайней мере он узнает много буковок и их расшифровки. Он даже сможет из статьи почерпнуть, что сервера бывают не только 1С и баз данных, но и web. А если про web сервера он слышал, то будет в курсе, что там есть загадочный серверный язык PHP. Хотя я на нем и формы далеко не web рисовал (gtk for php было интересно попробывать). Правда о конкуренте его C# или VB которые в ASP и ASPX используются почему-то не упоминается, так же как и о perl, python, с и т.д…
Ну да бог то с ними убогими — программисту 1С не предстало думать о не предметноориентированных языках программирования. Но родной 1С то зачем так эссить? Он намного более 1С нежели one ass, как о нем принято отзываться. Да он не идеален, но не так убог как написано. А прочитав статью новичек-одинэссник и так эссник по коду пока, будет костыли делать, вместо того, что бы из эссника в 1С программиста превратиться.
Прямые POST запросы с помощью HTTPСоединение, как показала практика, не могут передать не закодированные данные… и как результат многим сайтам не передать информацию (файл)…
(16) Если прочитать двоичные данные в обычную строку, как в php или perl, то передать можно. Но штатных средств в 1С нет. Об этом я писал ещё два года назад
(17) Да видел я твою статью, использовал ее за основу…
Проблема в том, что ты не сможешь штатными средствами перегнать двоичные данные в строку (без кодирования), корректно уж точно… Я убил на это дня два, плюнул, и написал на жаве…
(18) Ты глухой? Я об этом и пишу. >>> Но штатных средств в 1С нет.
(19) Не хами. Зачем тогда вообще что то писать в (17) если в (16) я все озвучил.
(9) Я вас понимаю, бредом можно назвать все, с чем не согласен.
(21) Бредом я называю не то с чем не согласен. А то что априори неверно. Все вопросы из 9-го поста риторические. Ответы на них предопределены:
1. Web сервисы не повышают масштабируемость приложения. Web сервисы добавляют функционал.
2. А никакого. Это разные вещи, как топор и скальпель хирурга.
3. Запросы подменить так же просто, как и файлы (если не проще).
4. Да не нужно этого делать. Для этих вещей прекрасно подходят OLE, COM или файловый обмен. Нет необходимости городить огород.
5. Web формы настроить можно, так как хочешь. Просто надо:
а. Уметь это делать
б. Не забывать, что всегда есть обходной вариант.
Про последний абзац. Web сервисы SOAP я писал еще к семерке, как клиентов, так и серверов. В восьмерке можно глянуть и никаких HTTPСоединение не надо городить.
(22)
1. Да, пожалуй это единственный пункт с которым соглашусь. Нужно было другой термин применить. Исправил.
2. Ну да, разные, и что? Хочу, использую веб-формы, хочу — веб-сервисы. Все зависит от потребностей. Да я и не пытался их сравнивать. Даже не понял, с чего вы это взяли.
3. Нет, не так просто.
4. Можно использовать COM, а можно веб-сервисы и никакого огорода здесь нет, потому что сети бывают разные и не везде COM поднимете. Разработчик PHP, работающий с вами в компании, для реализации внутреннего проекта никакой COM 1с поднимать не будет — ему проще веб-сервисами общаться. Про файлы вам любой внутренний IT-аудитор скажет, что это небезопасно, более небезопасно, чем подменять запросы, хотя бы потому, что файл выгружает обычный пользователь, который на флешке может передать его куда надо, а подмена запросов и снифферство траффика — это другой уровень работы.
5. С чего вы взяли, что я говорил, что управляемые формы не настраиваются? Или вы хотите поспорить, что интерфейс, реализуемой в управляемых формах, настолько же гибок, как если бы я рисовал интерфейс с применением озвученных в статье технологий? Как вы выразились, априори, интерфейс написанный при помощи html+php+javascript во много раз гибче и функциональней управляемых веб-форм 8.2, но его сложнее реализовывать.
(23)
2.
Поясняю. Web интерфейс к 1С — это интерфейс доступа к ее данным через браузер. То есть связка httpd — 1C — sql(dbf), на худой конец (интерфейс к данным 1С) httpd — sql(dbf). Если рассматривать вашу схему httpd — httpd — 1C — sql(dbf), то получаем как минимум лишнее звено. Это называется уже не интерфейс к 1С — это межплатформенное взаимодействие. В вашей схеме интерфейс к 1С закончился на web сервисе. Вы конечно можете использовать что и как хотите, но сути это не меняет. Это не основа для web интерфейса — это и есть web интерфейс.
3. Я про подмену на стадии передачи, а вы? С помощью брандмауэра уровня приложений менять http запрос одно удовольствие, не верите? А зря. С помощью брандмауэра сетевого уровня — сложнее, но то же ничего сложного. При этом если файлы реплицировать через ssh протокол, то такое просто не получится. Так как ssh шифрует файл на входе и дешифрует на выходе + подпись. В лучшем случае придет битый файл. Хотя я такого за 5 лет работы ни разу не встречал.
4.
а. Безопасность смотри п.3, а если ты про https, то у 1С не все с ним в порядке, а точнее тебе нужен не самопальный сертификат, для нормальной работы. Да и наличие его не гарантирует безопасность, т.к. если у клиента сертификата нет, то шифруется только трафик от сервера к клиенту.
б. А если ты про то, что у сервака не обрезаны usb порты и не настроена безопасность, то это к квалификации админа претензии.
в. Ты общался с PHP программистами? Они SOAP на дух не переносят. Просто потому, что PHP его не кэширует и это потенциальная DoS дыра, а еще потому, что файлы с сервака читать проще и им ниабет как они туда попадут. Хотя их заставить то же можно — вот только рады они этому точно не будут.
г. Обмен с сайтом — это не web интерфейс к 1С. Это см п.1 межплатформенное взаимодействие.
5.
а. С чего взял:
б. А на ассемблере наиболее гибок. Если надо дать доступ к 1С удаленным пользователям, то отношение прибыль от решения / время * ресурсы для разработки при использовании управляемых форм будет не сопоставимо выше чем php+javascript. И я еще десять раз подумаю, а не использовать ли ShareApp или терминальный сервер.
Ваша связка (php+javascript) имеет право на жизнь только когда надо дать доступ неограниченному числу пользователей. Здесь у 1С возрастает показатель ресурсы для разработки, а точнее поддержки. Но эта задача не 1С. 1С — это ERP, CRM, HRM и т.п., а не CMS система (хоть она и может поддерживать обмен с ними).
(24) Игра словами.
Про подмену http запроса. Вы сначала доберитесь до места в сети, где будете перехватывать. Речь о том, что файловая подмена реальна на уровне пользователя, а если используется удаленное взаимодействие, то при прочих равных условиях гарантированно на клиента придут данные, заложенные разработчиком в логику системы.
Да, я общаюсь и с PHP, Perl, Python разработчиками. Никто и в страшном сне не придумал общаться с 1с по COM. Все прекрасно общаются по SOAP и это признанный стандарт. PHP прекрасно кэширует wsdl.
Да, управляемый интерфейс сильно шаблонизирован, по моему это очевидно. Настраивать формы «галочками» можно — для быстрой разработки самое то, я не спорю, но дальше галочек дело не пойдет. Все зависит от решаемых задач и реализуемых проектов. Если в команде есть грамотный верстальщик, то все, что мне нужно — отдать ему наружу XML с данными, а он уж довольно быстро справится с отрисовкой и остальными вещами.
(26)
К чему я все это, а к тому что статья ни о чем.
Да, только Вы забыли подчеркнуть — ни о чем для вас. Если бы вы внимательно прочитали начало статьи — я так и спозиционировал ее, как базис для начинающих разбираться. Я даже и не собирался рассматривать глубже отдельные аспекты. Хотите большего — для специалиста вашего уровня есть куча специализированных ресурсов, официальных спецификаций и т.п.
Если убрать все ваши словесные экзерсизы (но я не в коем случае не сомневаюсь, что вы действительно специалист в тех областях, которые описываете), то вся ваша критика сводится к бональной демонстрации ваших познаний. И это прекрасно, что у вас такие глубокие познания. Возьмите и поделитесь ими, напишите отдельную статью для специалистов, в которой опишите все технические детали с приведением статистики, расчетом финансовых составляющих проектов, описанием морально-психологического климата в проектной команде и т.п. — все это интересно, но для другой целевой аудитории.
Общие фразы про все
Ну да. Только не про все, а «общие фразы» по вполне определенной тематике. И опять-таки, я в начале статьи об этом упомянул, что статья носит теоретический характер и привел ссылку в нелюбимом вами шестом пункте на вполне конкретный практический пример.
PS. В любом случае, спасибо, что уделили время и проявили интерес к «неинтересной» статье, хоть и посредством критики.
(26) В защиту автора, так сказать 😀 Статью, честно скажу полностью не читал, — проглядел по быстрому(просто времени нет), — но подозреваю 1С-никам больше и не надо знать. Зачем?
1. О какой подмене http запроса идет речь(чего-то я не нашел откуда это в статье) и самое главное как это связано с 1С?…CSRF, XSS, как-то далеко от 1С…
3. Какая разница какой язык? Смысл везде один…по моему…а синтаксис можно посмотреть, где-нибудь…
4. Ну он имел виду скорее всего гетерогенную среду, в контексте php (который в подавляющем большинстве на nix-ах) и всяких там обменов.
5. Да, soap, php — шники не любят, я тоже не люблю, ну и что…иногда бывает нужен soap — видел на php как клиентов, так и сервисы, в pear-ах есть по моему. Зато rest геморрой для конечного пользователя/программиста, в плане поддержки.(Но шустрый)… кстати в текущем контексте, тогда вопрос, никто не имел дело с wadl?
6.-9. Ну, да.
Резюме — Да, в статье — наверняка есть погрешности и ошибки, за которые на специализированном ресурсе могли бы распять (хабр какой-нибудь), но это ИС, — поэтому считаю данную статью ликбезом для начинающих 1С программистов…когда им захочется быть просто скромными программистами, возьмут найдут информацию, почитают книжки…
(28) спасибо конечно, но «Статью… полностью не читал», а потом «…наверняка есть погрешности и ошибки» звучит как-то не очень :). Я не претендую на точность формулировок, да и цели такой не ставил перед собой, хотя старался быть близким к оригиналу. Если есть неточности — говорите, поправим. Но явных ошибок быть не должно.
(26) скорее говорит не про ошибки, а про бессмысленность статьи, но эта «бессмысленность» субъективна. Вокруг много людей только-только начинающих разбираться. И им на данном этапе точно не нужна точность и детальность — это их еще больше запутает.
(29) нормально, — я думаю, ошибку, если постараться, можно найти где угодно(не ошибается только тот, кто ничего не делает), — вопрос не о том. А смысл — а наша жизнь имеет смысл? смысл он по ходу пьесы придумывается…
(28)
1. Ну не я про подмену начал, а автор коммент (23) п.4
2. Смысл один, да подходы разные: ООП, сервис ориентированное программирование, процедурное или функциональное. Но когда знаешь С++ — С# и java на ура изучаешь.
4. И?
5. Я имел дело с WSDL. Мне даже соап нравится больше чем REST с ним геммороя в 1С и не только меньше. В чем вопрос?
6. Ну да 6 пункт статьи моловат и вреден. Его бы переписать и я автору плюсану.
(29) Я говоря о пользе статьи и вредности пункта 6 в таком виде. Его надо расширить и убрать слова:
(31) Пункт 6 написан правильно. Ничего вредного в нем нет. И уж тем более не надо его расширять. Хотите читателя погрузить в подробности — пожалуйста, напишите свою статью и распишите там все, что хотите.
(31) в 5 я спрашивал про …интересны практические примеры
(33) Создания руками или генерации?
отличная статья! как раз для таких как я :), которые первый раз сталкиваются soap. Просто и доступно. спасибо!
Только начинаю вникать в связку 1С+веб-сайт(интернет-магазин) в смысле активного обмена данными. Статью прочитал полностью и считаю ее заслуживающей внимания просто для понимания самого механизма. Работал в компании, где для обмена информацией с WMS системой был поднят сервер Apachi и написаны php скрипты для вызова процедур обмена между 1С и WMS. Автору спасибо! Тем более, что от разработчиков 1С вменяемых мануалов вообще нет!!!!
Добрый день. Мы создали платформу Agora на PHP, которая позволяет значительно упростить вопрос обмена не только с 1С.
Кому интересно, заходите на наш сайт http://www.centrobit.ru
Понимаю, что это жесткая реклама, но проблему мы действительно решили, поскольку на данной платформе реализовываем B2B интернет- магазины, в которых вопрос обмена данными стоит гораздо острее — там нужно и резервирование товара настроить и финансовые взаимоотношения вести и проч. Подобные проекты реализовываем за 2 месяца.
Другое дело, что стоит это счастье не дешево… В любом случае, будем рады любым обращениям и вопросам по данной тематике.
Статья мне очень помогла
Тоже не увидел особенного применения и чего то того, что не было описано в источниках на которые вы сослались.
Если вы говорите о
Но это же бред, с таким же приколом засуньте в хмл хеад описание структуры и вперед.
Преимущество soap далеко не в этом.
К тому же, то что уже выше описали, просьба убрать из статьи высказывания: (Пометил жирным)
Так как не только специалисты читают эти темы, и могут понять, где человек слегка перегнул палку, но и клиенты, которые потом будут кричать, что их развели, так как управляемый интерфейс — это чушь.
Или убедите в обратном.
Так как если уж вам ОЧЕНЬ сильно надо что то сделать этакое, то вам в помощь веб поле, которое подерживает ява скрипты и пилите что угодно. (при чем в нормальной связке с 1С)
Нельзя! Связка двух баз делается планами обмена, и не спроста — открою вам секрет. Или же вы просто не работали с большим количеством баз, которые тесно связаны. Если вы будете делать это через соап, то это чистый развод клиента.
Да, через соап можно передавать файл выгрузки хмл из планов обмена, но он играет лишь роль транспорта в таком случае. И то, не всегда успешно справляется.
Тот бред который описан ниже, в этом параграфе, опущу. Так как это по сути будет реализация велосипеда, и чистая выкачка денег с клиента.
Та и вообще, у вас в статье ни о чем не сказано, я таки положительно не знаю куда копать. Вы что то описали, рассказали, налили воды в текст и все.
Лучше бы уже сделали просто подборку ссылок по затронутым тут технологиям и не пытались писать реферат.
(34) awk, почитывая комментарии я понял, что вы просто кроме 1С не умеете больше ни с чем работать к сожалению. Поэтому так агрессивно воспринимаете других, кто 1С воспринимает лишь как данность печальной российской действительности. К сожалению 1С это боль и горе российского ПО, отвратительно написанная программа, навязанная везде и вся с которой вынуждены считаться люди и вникать в этот жуткий бред, натыкаясь на низкий уровень квалификации самих программистов 1С
(37) Centrobit, вы сами пользовались тем что создали? нам 15 минут хватило, чтобы больше никогда не пользоваться этой «платформой». Это обычный сайт, сделанный на скорую руку с кучей глюков. Ввод организаций без ОГРН ИНН никак? а если я просто хочу вести CRM? в IE страницы выползают за поля и не видно заголовков. Поиск по системе — нет не слышали, я уж молчу про онлайн поиск без кнопки «найти», прикрутить движок непосильная задача видимо)))) по организациям поиска нет, по товарам тоже быстро не нашли — но наверно есть, иначе это эпик фейл. И совет — выбросьте движок GUI ваш на помойку, он сбоит по страшному так, что работать невозможно с системой. Все очень сырое и функционал не дотягивает даже до банального инет магазина, зато реклама пафосная на ютуб на которую я и купился. Не обижайтесь на мою критику — я просто честно все вам высказал, есть с чем сравнивать. Платформа — это когда можно настраивать не контент (перечень товаров), а АРХИТЕКТУРУ — поля, типы данных, логику взаимодействия. От того что вы назовете свой сайт платформой он платформой не станет. Зря вы написали про ваш продукт — это антиреклама. Причем убийственная
(42) Neverpoint,
Напишите лучшее ПО… :))) Когда дойдете до: «ну его на …» отпишитесь… Агрессию у меня вызывают критики, которые дальше puts «helo world» не шли… Причем с обоих сторон (1С и и не 1С)….