Допускается разработка веб-приложений на различных языках программирования и языках сценариев. Internet Information Services (IIS) использует расширение имени файла ресурса, запрошенного на веб-узле, для определения программы ISAPI или CGI, которую следует запустить для обработки запроса.
Например, запрос на файл с расширением имени .asp приводит к тому, что веб-сервер вызывает программу ASP (Asp.dll) для обработки запроса. Связывание расширения имени файла с программой ISAPI или CGI называют сопоставлением приложения. В конфигурации IIS предустановлена поддержка общих сопоставлений приложений. Имеется возможность добавить или исключить сопоставления для всех приложений на веб-узле или для отдельных приложений.
- В оснастке Internet Information Services выберите веб-узел или исходный каталог приложения.
- Откройте окно свойств каталога и выберите вкладку Домашний каталог, Виртуальный каталог или Каталог.
- Нажмите кнопку Настройка и выберите вкладку Сопоставление приложений.
- Нажмите кнопку Добавить и в поле Исполняемый файл введите путь к программе ISAPI или CGI, которая должна обрабатывать такие файлы. Необходимо указать программу, находящуюся в локальном каталоге на веб-сервере.
- В поле Расширение введите расширение имени файла, которое требуется связать с программой ISAPI или CGI. При получении веб-сервером адреса URL, в котором задан файл с таким расширением имени, для обработки запроса будет вызвана соответствующая программа.
- Чтобы разрешить обработку файлов этого типа в каталоге с разрешением «Сценарии», установите флажок Обработчик сценариев. Если для каталога задано разрешение «Сценарии» (в отличие от разрешения «Выполнение»), то в этом каталоге будут обрабатываться только файлы, связанные с приложениями, которые обозначены как обработчики сценариев.
ЭТИ ПРОГРАММЫ ПОВЫСЯТ ТВОЙ FPS? СРАВНЕНИЕ ПРОГРАММ ДЛЯ ОПТИМИЗАЦИИ WINDOWS 10
Важно! В окне свойств Отображение приложений имеется столбец с именем Команды. В IIS 4.0 этот столбец имел имя Исключения; изменения команд обеспечивают совместимость с будущими версиями и добавлением новых команд HTTP к протоколу Hypertext Transport Protocol.
Чтобы удалить сопоставление приложения
| На вкладке Сопоставление приложений выберите расширение имени файла и нажмите кнопку Удалить. Запросы на файлы с таким расширением имени более не будут обрабатываться на этом веб-узле или в каталоге. |
Источник: codenet.ru
Интеграция программного обеспечения. Описание процесса от бизнес консультанта
Синерги́я (греч. συνεργία — сотрудничество, содействие, помощь, соучастие, сообщничество; от греч. σύν — вместе, греч. ἔργον — дело, труд, работа, (воз)действие) — суммирующий эффект взаимодействия двух или более факторов, характеризующийся тем, что их действие существенно превосходит эффект каждого отдельного компонента в виде их простой суммы[1], эмерджентность.
Восстановление файлов – какая программа лучше? Сравнение программ для восстановления данных
В процессе работы бизнес консультантом, для увеличения эффективности работы систем предприятия, я почти всегда предлагаю провести интеграцию между различным ПО заказчика. Потому что интегрировав различные системы возможно добиться эффекта синергии.
Мне постоянно приходится сталкиваться с одними и теми же проблемами и решениями многие из которых приходится пояснять в каждом новом проекте заказчикам, некоторые – программистам. А потому я считаю, что о процессе интеграции стоит поговорить подробно. В большинстве примеров я выбрал различные случаи интеграции 1С и CRM, так как сегодня именно этот вопрос, как показывает моя практика, наиболее актуален. Хотя данная статья подойдет при интеграции практически любого программного обеспечения. Итак начнем.
Интеграция – это очень важная часть работы по автоматизации бизнес-процессов, так как требуется она постоянно. В разных ситуациях возникает потребность оперативно обмениваться данными между различными конфигурациями 1С, между программными продуктами 1С и сайтом, между 1С и CAD системами, а также системами биллинга и т.д. Также достаточно часто требуется интегрировать между собой различные веб сервисы, например, интернет-магазин и CRM-систему. В общем, объединить работу различных подразделений компании и автоматизировать рабочий процесс без использования интеграции в большинстве случаев невозможно.
Что такое интеграция?
Википедия дает нам такое определение:
- Веб-интеграция — объединение разнородных веб-приложений и систем в единую среду на базе веб.
- Интеграция данных — объединение данных, находящихся в различных источниках и предоставление данных пользователям в унифицированном виде
Я считаю, что в данном случае Вики абсолютно права. И дополнить ее можно только одним определением:
Интеграция программных систем и продуктов — это обмен данными между системами с возможной последующей их обработкой.
Смысл интеграции заключается в том, чтобы данные, которые пользователь вводит в одну систему, автоматически переносились в другую. Продукт, в который пользователь вводит данные, называется источник. А получатель данных, соответственно, приемник.
Достаточно часто данные переносят в обе стороны, например, после преобразования в системе-приемнике результаты отправляются обратно в источник. А потому интеграция бывает как односторонней, так и двухсторонней.
Например, если вы объединяете конфигурацию 1С: Торговля с 1С: Бухгалтерией, вам может потребоваться передать данные по всем продажам в бухгалтерию, а обратно получить сведения об оплате по этим продажам.
- Определяем, какой продукт является источником, какой – приемником.
- Сопоставляем объекты между источником и приемником.
- Выбираем протокол для интеграции
- Проводим постобработку данных (после переноса в одну из сторон)
Важно: при интеграции различных программных решений нужно хорошо понимать их функционал.
Когда-то я и сам совершал такую ошибку, и брался за интеграцию программных продуктов, которые я недостаточно хорошо знал. А потому могу сказать точно: изучать программный продукт в процессе интеграции – это не совсем корректно. При таком подходе чаще всего возникает множество ошибок и проблем, например, перенос не тех данных или сбои в работе. Рекомендую сначала хорошо изучить программный продукт, понять, что он может, каким образом в нем реализованы те или иные функции, и только потом заниматься интеграцией.
В принципе, в процессе интеграции вам может потребоваться и более сложный обмен, и придется вводить, например, трех- или четырехстороннюю интеграцию. Но, по сути, эти процессы ничем не отличаются от обычного одно- или двухстороннего процесса. А потому я буду говорить об интеграции односторонней. А в конце скажу пару слов об особенностях двухсторонней. Все остальные направления вы всегда сможете выстроить по аналогии.
Выбираем источник и приемник
Для каждого случая интеграции данных важно четко определить, какая система будет источником, а какая – приемником.
Например, у вас есть система CRM и программа 1С: Торговля. В обеих системах существует такое понятие, как контактное лицо. В принципе, вводить его вы можете и с одной, и с другой стороны. В данном случае, очевидно, что источником стоит назначить CRM, так как этого требует логика работы с любой CRM-системой.
Аналогично и в других случаях. Нужно понимать, в какой системе пользователь будет вводить данные, а какая станет получателем этих данных через интеграцию. Это обязательно согласовывается с клиентом (пользователем), кроме случаев, когда источник очевиден. при этом обязательно нужно поставить в известность клиента, что данные определенного типа следует вводить именно через систему-источник.
Сопоставление объектов (данных)
Каждый раз при работе с данными нужно очень хорошо понимать, что именно вы выгружаете, в каком виде, а также, куда вы будете выгружать эти данные. В некоторых случаях в источнике у вас будет строковая переменная, а в приемнике – два или более объектов. В других важно просто правильно выбрать объект-приемник.
Например, практически в любой CRM контактное лицо и клиент – это одно и то же. С другой стороны в 1С контактное лицо может быть клиентом, партнером, поставщиком. И очень важно понимать, куда именно записывать данные этого контактного лица. Также важно сопоставлять все данные до того, как начнется работа непосредственно с кодом. Для этого прекрасно подойдут таблицы или блок-схемы.
Когда-то я так же, как и многие, пренебрегал этим этапом работы. Сейчас я знаю, что эти действия позволят избежать огромного количества ошибок. На какой бы стороне ни работал программист – на стороне программы-источника или приемника, такая табличка очень помогает в работе. Программист должен четко понимать, какие данные будут брать из источника, куда их нужно переносить, и как они будут обрабатываться.
Например, при выгрузке контактного лица из CRM нужно четко сопоставить этот контакт партнеру или покупателю.
Также очень важно понимать, какие преобразования потребуются для выгружаемых данных. Например, нужные для интеграции данные в источнике хранятся в качестве перечисления в виде текста. А в приемнике (пусть это будет 1С) аналогичное перечисление имеет ссылочный тип. Следовательно, вам потребуется преобразовать текст в ссылку, и уже ссылку передать в документ.
И здесь возникает проблема: требуются правила сопоставления.
Вы должны четко продумать и прописать правила сопоставления. Более того, об этих правилах необходимо оповестить ваших клиентов. Важно понимать, что клиент не видит логику работы обмена данными, он не понимает особенностей интеграции.
Также стоит лог-файл ошибок вести максимально подробно и как можно дольше хранить историю. Не забывайте, что вы имеете дело с данными, которые имеются в одной базе данных, но отсутствуют в другой. И без подробного отчета вам будет очень сложно понять, что именно произошло в процессе передачи данных.
Обмен данными: писать самому или применять типовое решение?
Лично я предпочитаю всегда разрабатывать решение под заказчика. Здесь можно спорить, можно обсуждать различные варианты, но есть факт: типовые обмены данными всегда сильно перегружены возможностями, которые вашему клиенту не нужны. В результате процесс обмена значительно замедляется, а число возможных ошибок вырастает в разы.
Кроме того, при выборе типового программного решения вы очень сильно зависите от поставщика программного обеспечения. Для любого исправления бага вам придется ждать выпуск очередной версии программы. Также придется подстраиваться при обновлениях под все изменения в работе, который внес разработчик.
А потому при выборе между самостоятельным написанием обмена данными и типовым решением, которое не на 100% подходит для данной ситуации, лучше писать обмен самому.
В некоторых случаях, когда типовое решение действительно на 100% удовлетворяет потребности клиента, а скорость работы для него не критична, я также применяю готовые продукты. Например, при выгрузке номенклатуры и фотографий на сайт я не редко использую готовый обмен данными от Битрикс. Но только для выгрузки. Для работы с заказами я применяю самописный обмен.
Метод подключения: REST API, SOAP или прямое подключение к базе приемника
Выбор протокола обмена данными в большинстве случаев напрямую зависит от системы, которую вы интегрируете. В большинстве случаев программисту приходится учитывать требования обеих систем, а потому выбора как такового не существует. В тех случаях, когда система может работать с несколькими протоколами, выбирайте тот, который вам удобнее. По моему опыту, для малых и средних предприятий этот вопрос не принципиален.
Вопросы клиентского доступа: почему не работает обмен?
Я считаю, что обо всех возможных ограничениях в доступе нужно узнать на начальном этапе интеграции. Таким образом, вы гарантированно избежите очень распространенной проблемы:
Вы внедрили интеграцию, все проверили, протестировали, убедились, что система работает. После чего пользователь обнаруживает, что обмен данными не происходит.
- Ограничение доступа по IP.
- Ограничение прав пользователя.
- Ограничение по количеству обращений к источнику или приемнику
В случае работы с CRM-системой ограничения обычно обусловлены оплаченным пакетом услуг. Здесь достаточно оповестить клиента о наличии такого ограничения, и, при необходимости, помочь оплатить и настроить расширенный пакет.
1С идентификаторы и ошибки, связанные с ними
При интеграции с 1С очень часто ошибки обмена данных возникают из-за неверного выбора УИ (уникального идентификатора). Суть проблемы заключается в том, что объекты в 1С имеют два типа УИ: один уникален внутри выбранного типа объектов. Второй используется для работы со всей базой данных.
Если вы будете проводить поиск по всему справочнику с использованием идентификатора, который предназначен для работы внутри определенного типа данных, возникнет ошибка. Объект может быть вообще не найдет, либо система найдет сразу несколько разных объектов. К этой особенности 1С нужно относиться очень внимательно.
Еще одна проблема: нет возможности привязаться к уникальному идентификатору.
Например, системой-источником является сайт, и на нем не предусмотрено отдельное поле для информации о клиенте, она идет в общем тексте заказа. В этом случае придется выбрать какой-то другой вариант идентификации, например, по email.
При интеграции очень важно выбрать в источнике одно из полей, которое и станет уникальным идентификатором.
Я считаю хорошим тоном дублирование этого идентификатора в двух системах. Например, если я делаю выгрузку информации из CRM в 1С, то поле-идентификатор из CRM я копирую в систему 1С. В дальнейшем весь поиск и интеграция производится по этому полю быстро и просто.
В принципе, это не обязательное действие. Более того, вы будете хранить даже избыточные данные, так как у вас есть нужная информация в одной из систем, но такое дублирование повышает надежность работы обеих программ и является удобным решением для интеграции и последующей обработки данных.
Например, по идентификатору, который идентичен источнику, поиск будет производиться проще и быстрее, так как он не будет требовать дополнительной обработки. Кроме того, если что-то случится с базой данных одной из систем, благодаря дублирующимся идентификаторам сопоставить данные будет намного проще.
Формат выгрузки
Для обмена данными используются самые разные форматы. Это может быть JSON, XML, CSV, TXT, прямой доступ к базе и т.д. У меня в этом вопросе нет каких-то определенных предпочтений. Я считаю, что здесь нужно исходить из рациональных требований проекта.
Постобработка
Итак, обмен данными прошел успешно. Что дальше? Я считаю, что это еще не финал интеграции, так как пользователю мало того, что данные появились в системе. Обычно ему требуется, чтобы с этими данными выполнялись какие-то действия. Что именно нужно клиенту, следует уточнить у него.
Но всегда надо помнить о том, что вы работаете для пользователя, для того, чтобы ему было удобно.
- Оповещение менеджера о поступлении заказа, например, при помощи sms
- Уведомление пользователей о поступлении новых заказов или другой актуальной информации по email
- Звуковой сигнал и/или всплывающее окно в 1С с напоминанием о том, что появились новые запросы или заявки
Кроме действий, которые нужно выполнить в приемнике, также часто требуется после завершения успешной передачи данных выполнить определенные действия в источнике. Что именно потребуется, вам также расскажет пользователь.
Например, это может быть уведомление клиента о том, что его заказ успешно прошел выгрузку и отправлен в обработку. И здесь также может быть использовано sms, электронное письмо или просто изменение статуса заказа в системе.
Тестирование интеграции
С моей точки зрения интеграция – это часть (иногда частный случай) внедрения программного обеспечения. И здесь, как и для любой другой работы по внедрению ПО, потребуется тестирование программистом, потом – лично консультантом, а также различные варианты тестирования вместе с пользователями. Об этом я подробно писал в статье Внедрение программного продукта.
Особенности работы бизнес-консультанта. Часть III. Финальная.
Отличие односторонней и двусторонней интеграции
На самом деле, принципиальных отличий у односторонней, двусторонней или многосторонней интеграции не существует. Суть процесса остается прежней, просто в разные моменты времени приемник и источник меняются ролями. Единственное важное правило, которое я ввел для себя и вам также советую: при двухстороннем обмене необходимо хранить уникальный идентификатор для всех систем, которые участвуют в интеграции. И я считаю, что его также стоит дублировать в обеих системах.
Сегодня я постарался кратко рассказать об особенностях процесса интеграции, с которыми я лично сталкиваюсь на практике. Я надеюсь, что статья оказалась для вас полезной, а если возникнут какие-то вопросы, я, как и всегда, готов на них ответить.
- интеграция
- интеграция приложений
- интеграция с 1с
- обмен данными
Источник: habr.com
Первые сопоставления программ и проектов
Для Московского методологического кружка постановка вопроса о сопоставлении программ и проектов, о сопоставлении проектирования и программирования, проектного и программного подходов — является достаточно новой. Вероятно, в отчетливой теоретической форме этот вопрос был поставлен в связи с проведением первых организационно-деятельностных игр (ОДИ), посвященных разработке программ НИР в области дизайна. На наш взгляд, сама ситуация появления такого вопроса не является ординарной, поскольку предполагает тесное взаимодействие представителей трех сфер (областей) деятельности: организационно-управленческой, проектировочной и методологической. Попробуем кратко реконструировать предысторию возникновения этой ситуации.
Исходным носителем практики разработки программ (с исторической точки зрения) следует, очевидно, считать сферу организационно-управленческой деятельности. Для этой сферы программы — это традиционные документы особого рода, необходимость в которых возникает в таких случаях, когда требуется гибкая, динамичная (ситуативная — добавим мы сегодня) организация деятельности, работ, действий (таково, как правило, назначение программ политических партий). Обращение к программам, как к средствам организации, возобновляется в истории организационно-управленческой деятельности всякий раз, когда в силу неопределенности ситуации управления и (или) наличия в ней одновременно нескольких автономных фокусов организации — не удается осуществлять эту деятельность в директивах, жестко установленных формах. С этой точки зрения, практика организации на основе программ может быть, например, противопоставлена практике организации на основе планов. Невозможность использования планов при неопределенности ситуации управления достаточно очевидна и, по-видимому, на сегодняшний день осознана в сфере ОРУ. Плановая форма организации требует не только жесткого задания конечных результатов деятельности, но и средств, последовательности действий, сроков их осуществления, ресурсного обеспечения и т. д.
Ситуации взаимодействия организационно-управленческой деятельности и проектной являются весьма характерными для XX века. Так, а области архитектурно-градостроительного проектирования за последние 100 лет произошли очень большие изменения: практика персональных заказов и возможность организации всех работ под директивным руководстве архитектора сменилась практикой «коллективного заказа» и многофокусной (и с необходимостью ~ неопределенной, ситуативной) организацией работ.
В этих условиях архитектурный проект перестал выполнять функции директивного средства организации, более того, в процессе разворачивания работ его приходится подвергать многократным перестройкам. В этих условиях организационный аспект деятельности архитектора, бывший ранее на втором плане, входящий в состав обслуживающих средств архитектурной работы, начинает выдвигаться на первый план. Эти аспекты начинают определять не только общий характер организации работ, в том числе и характер разработки проекта, но и внедряться в саму проектную действительность. Сегодня это уже не действительность вещей, сооружений, а действительность условий деятельности, жизнедеятельности людей, сегодня проектировщик начинает осознавать себя как организатор этих условий, а проект в его традиционной форме и содержании становится лишь одним из средств такой организации.
Итак, современная практика проектирования постоянно создает ситуации, в которых программы как средства организационно-управленческой деятельности и проекты используются в общей системе организации работ. Однако, такие ситуации еще не являются ситуациями постановки вопроса о сопоставлении программ и проектов (как можно сопоставлять программы организации работ с проектами вещей?).
Возникновение такого вопроса предполагает, очевидно, возникновение ситуаций, в которых проекты и программы могут претендовать на выполнение одних и тех же функций. Появление таких ситуаций стало возможным сравнительно недавно — в результате как бы ответной экспансии проектирования, проектного подхода в сферу организационно-управленческой деятельности и становления организационного проектирования.
Это, в свою очередь, стало возможным только после того, как в проектировочном движении была осознана стратегия перехода от проектирования вещей к проектированию систем деятельности. Даже у самого термина «проект» с этого момента появляется второе значение; проектами начинают называть большие целевые системы организации работ (в военной промышленности, в космических разработках, в здравоохранении, экологии и т. д.).
Появление такой организационной практики и активное использование в ее рамках проектного подхода как основного подхода в искусственной работе с «будущим» приводит к тому, что у программ и проектов появляется один объект организационного действия. Однако, сама эта ситуация в рамках организационно-управленческого и проектировочного профессиональных сообществ не является, по-видимому, осознанной до настоящего времени.
Термины «программа» и «проект» часто используются как синонимы, и, вероятно, для практических ситуаций этот вопрос не имеет особой остроты и вряд ли может там возникнуть. Чтобы возник вопрос о теоретическом различении функций и специфического содержания планов, проектов, программ, должен быть специально поставлен вопрос о развитии средств организационно-управленческой деятельности. И вслед за этим должны появляться специальные теоретические и методологические разработки, обеспечивающие такое развитие. Фактически это и означает, что сфера методологии является третьим необходимым участником в тех ситуациях, в которых может быть поставлен вопрос о сопоставлении программ и проектов.
Итак, с появлением организационного проектирования программы и проекты могут впервые быть сопоставлены, поскольку имеют общую организационную действительность. В чем может быть тогда зафиксировано основное исходное различие организационного содержания программ и проектов?
Очевидно, исходная (и традиционная) функция проекта состоит в задании представления о конечном результате деятельности. В отличие от проекта, программа ориентирована, прежде всего, на задание представления о самом процессе деятельности. Если рассматривать теперь проектный подход как универсальный, то мы можем задать вопрос, может ли такая организационная специфика программ быть снята в рамках проектного подхода? Или иначе: может ли сам процесс деятельности быть спроектирован (может ли программа быть спроектирована?) Вероятно, при определенных условиях, такое двойное употребление проектного подхода — и для задания представлений о конечном результате деятельности, и для задания представлений о самом процессе достижения этого результата — возможно. Фактически, планы сегодня и являются таким результатом двойного использования проектного подхода.
А может ли быть в средствах проектного подхода ассимилирована другая специфика программ — как средства гибкой, ситуативной организации деятельности? Очевидно, что изменение организационных условий потребовало бы изменения спроектированной системы организации работ и, возможно, даже изменения представлений о конечном результате этих работ.
Попытки справиться с такими проблемными для проектирования ситуациями предпринимаются в последние годы в стратегиях «среднесрочного» и •перманентного» проектирования. Стратегия среднесрочного проектирования делает упор на отказе от долгосрочных проектов в силу их очевидной нереализуемости из-за значительного изменения условий работ за время реализации проекта.
Среднесрочный проект предполагает осуществление достаточно масштабных работ (в отличие от краткосрочного) при достаточно определенной ситуации за время их реализации. Таким образом, масштаб работ и их характер, согласно этой идее, должен быть приведен в соответствие со степенью определенности и управляемости ситуации на базе этого проекта. Стратегия среднесрочного проектирования — это стратегия элиминирования ситуации, введения ее в границы учитываемых изменений. Идея перманентности. появившаяся в проектировании (так же, как и во многих других сферах деятельности) а 20—30-х годах, предполагает, что упор делается не на проекте как таковом, а на процессе проектирования, который разворачивается параллельно процессу выполнения работ, опережая его лишь настолько, насколько это эффективно. Для каждого очередного шага разворачивания работ в содержании проекта должно быть определено лишь то, что необходимо для этого шага, и лишь настолько, насколько это позволяет определить конкретная ситуация работы.
Идея перманентного проектирования была развита и проработана в методологических средствах после начала работ ММК по формированию сферы проектирования Л О/. Развитие идей перманентного проектирования шло в рамках методологии в двух планах.
Во-первых, предполагалось изменение объекта проектирования: объектом проектирования должны быть не вещи и не вещные организованности, а системы деятельности. Проектирование вещей, с этой точки зрения, есть средство косвенной, «превращенной» (по Марксу) формы организации деятельности. Такое изменение объекта проектирования, очевидно, предполагает изменение средств и методов проектирования, оснащение его новым корпусом представлений — представлений о деятельности. Однако, изменение объекта проектирования еще не решает проблемы гиб- • кости и ситуативности. Поэтому в качестве второго направления развития проектирования необходимо было фиксировать появление в рамках проектной работы каких-то новых, инородных для него видов работ, в частности, работ по анализу ситуации, протезированию, выработке стратегии и т. д. Если расширение понятия проектирования за счет задания нового объекта проектирования еще сохраняло подходную определенность проектирования, то такое расширение круга средств, методов и процессов в рамках самого проектирования во многом лишало бы его этой определенности.
Первые сопоставления программ и проектов
(С. Наумов. Представления о программах и программировании в контексте методологической работы. — Журнал «Кентавр» №1 –1991)
Источник: conflictmanagement.ru