P.S. Сегодня, 25 февраля 2017 года, когда я переношу свои публикации на новую платформу и читаю это, хочется пояснить — я не был пьян, когда писал это, просто много работал. Далее текст от 18 декабря 2011.

Пришла в голову крутая идея как можно интегрировать веб-приложения с минимальными требованиями к ним самим. Шире говоря, это идея как можно изменить автоматизацию предприятий, интегрируя не на уровне приложений, а на уровне браузера!

Задачи Enterprise Browser

Корпоративный браузер должен свести критерии выбора приложений к их функциональным возможностям, отдав реализацию интеграционных требований в браузер.

Каковы современные требования по интеграции приложений?

Вот запросы по интеграции приложений и как это решается сейчас:

I. Унификация UI, чтоб приложения следовали корпоративному стилю.

Сейчас это решается шаблонами и возможностями самих приложений. Обычно устанавливается логотип компании. Такие возможности есть, но не во всех приложениях. Надо иметь ввиду, если Вы занимаетесь кастомизацией на уровне HTML/CSS - она может слететь при обновлении.

II. Унификация авторизации.

Сейчас есть технологии SSO, но нужна поддержка со стороны приложений.

III. Использование приложения в бизнес-процессах.

Для вызова движком исполнения бизнес-процессов, приложение должно обеспечить веб-сервисы (SOAP, REST и т.п.). Однако, не всегда этот вызов будет из-под пользователя выполняющего действие в БП - для этого должны поддерживаться стандарты WS-*, а это ещё большая редкость, чем просто SOAP, который так же поддерживают не 100% приложений.

Во всех перечисленных выше случаях, мы видим один общий момент - интеграция должна поддерживаться приложением! И это сужает выбор приложений. Я, наверно, не ошибусь если скажу, что из 100% приложений, имеющих пользовательские интерфейсы, не более 10% как-то удовлетворят потребности предприятий в части II и III.

Enterprise Browser, реализованный как я опишу ниже, во многих случаях, особенно в малом бизнесе, перечисленные требования позволил бы снять.

Другие возможности Enterprise Browser

Что ещё можно требовать от Enterprise Browser?

1) Мониторинг здоровья приложения.

Объективно, кроме доступности UI и доступности БД, для большинства веб-приложений, ИТ ничего не может мониторить. Между тем, хотелось бы отслеживать время отклика и видеть когда оно растет или случается сбой и какие были введены данные.

2) Контроль качества данных.

Пользователи могут неправильно использовать поля. Они постоянно это делают! Если где-то можно ввести адрес или телефон в произвольной форме, там будут самые разные форматы адресов и телефонов. Пользователи указывают фамилию имя и отчество клиента в поле "Описание", когда есть поле "ФИО" и т.д.

Сейчас забота о качестве данных — забота приложения. Можно преложить на браузер.

Требования к Enterprise Browser

Корпоративный браузер должен централизованно администрироваться. Это относится ко всем функциям описанным ниже.

Далее опишу мои функциональные требования к Enterprise Browser в порядке убывания полезности с моей точки зрения. Полагаю, Вы ко мне присоединитесь.

Движок для сценариев

Словом "сценарий" обозначается набор последовательно заполняемых по определенным правилам форм, где следующая форма зависит от данных введенных в предыдущей. В реальности, очень много недокументированных на данный момент бизнес-процессов в огромном количестве организаций могли бы быть заменены сценариями.

В самых разных организациях пользователи вводят данные в несколько систем в определенном порядке. Да, двойной и тройной ввод повсеместен! А ещё бывает нужно сделать заявку в системе Х, а затем в системе Y проставить номер только что зарегистрированной заявки. Эти устоявшиеся (изредка документированные) бизнес-процессы могли бы сразу стать автоматизированными без замены приложений.

Вообще, везде где делается copy-paste из одного веб-окна в другое мы могли бы иметь автоматическую вставку или кнопку рядом в формой ввода или другую интерфейсную функцию, которая позволила бы нам использовать только что введенные или найденные в соответствии с нашим бизнес процессом данные.

Пример того, как может быть реализована работа по сценариям:

1. Корпоративный браузер по текущему сценарию открывает окно 1, где внизу нужной формы, вместо кнопки Submit, браузер показывает кнопку перехода на следующий шаг, возможно с выбором вариантов перехода.
2. При нажатии на кнопку перехода, браузер отправляет данные формы и, если результат соответствует ожидаемому, открывает окно 2, соответствующее следующему шагу. Данные, возвращенные в браузер в результате предыдущего шага (1), например, присвоенный номер договора или заявки, браузер автоматически вставляет в нужные поля в окне шага 2.

Что нам это дает?

Например, если на шаге 1 сотрудник абонентского отдела заводит данные абонента в биллинг, а на шаге 2 создает заявку по номеру договора в другой системе — мы снимаем требование к системе заявок по интеграции с биллингом на уровне договоров и избавляем пользователя от выбора № договора. Либо, это избавляет новичков от чтения, а значит от нарушения инструкций.

Теперь мы можем делать вставку в систему заявок нашего партнера или арендовать систему заявок в Интернет.

Окна поиска по данным других систем

Представим себе, что мы просто открыли форму заявки и нам нужно вставить туда номер договора. Вполне можно было бы рядом с текстовым полем, куда нужно этот номер договора ввести, отобразить значок поиска по БД договоров, и при нажатии, открыть окно поиска по данным договоров.

Выборка данных может быть реализована на серверной стороне решения Enterprise Browser уже неважно как, но пожалуй должны поддерживаться, как минимум, SQL запросы к целевым БД. Вставка данных могла бы быть замещающей содержимое поля или в текущую позицию ввода. Опционально для полей, к которым добавлено окно поиска, должно быть можно исключить произвольный ввод.

Этот функционал адресует те же потребности, что и движок для сценариев, но, во-первых, может использоваться помимо сценариев, а во вторых, не только в случае поиска по другим системами. Предположим, мы хотим ограничить количество заявок на день - можно было бы к полю даты прикрепить поиск ближайшей даты и исключить оттуда дни, на которые зарегистрировано уже более 10 заявок.

Обращу внимание, многим хочется добавить совсем немного бизнес-логики в действующие системы и нечто на уровне поля - вполне достаточно.

Создание связанной записи в другой системе быстрым действием

Рассмотрим такой пример - клиентской службой используется система заявок абонентов, а отделом контроля качества система учета жалоб. Две разные системы и это может быть нормально, т.к. требования разные, наборы состояний для жалобы и для заявки разные и требования по доступу к жалобе и к заявке так же могут различаться. Ещё пример - система заявок у филиала своя, а система учета жалоб у холдинга единая.

Хорошо бы, чтоб сотрудник отдела качества мог, нажав заявку в системе X правой кнопкой мыши, создать в системе Y запись на основе этой заявки, указав там "по заявке в X №:<номер>". Ведь браузер в DOM модели может распознать структуру записи, соответствующую заявкам в системе Х. Открыть и заполнить форму в системе Y он тоже может.

Это, в сочетании с функционалом окна поиска по данным других систем, открыло бы потрясающие возможности для BI потому, что быстро повысилось бы качество данных. У нас в разных системах не было бы ссылок на данные, которые нельзя было бы анализировать. Можно было бы с высокой точностью посчитать количество жалоб по заявкам определенного исполнителя, даже если жалобы и заявки в разных системах и эти системы никак не связаны.

Кроме того, решение можно дополнить функционалом перехода по ссылке, которая формировалась бы на основе формата указания на связанную запись. Например, если системе Y есть текст "по заявке в X №:<номер>", значит это ссылка на систему X, и можно её подсветить и реализовать переход на соответствующий URL.

Расширенная валидация и модификация полей

Если в приложении не хватает возможностей валидации, а иногда нехватает элементарного RegExp-а например, почему бы её не сделать корпоративному браузеру?

Стоило бы полям где в тексте должна быть дата прикрепить календарь, если его там до сих пор нет. Тут поле для фантазии вплоть до открытия кастомной браузерной формы, по которой заполняется реальное текстовое поле на странице (произвольное с т.з. веб- приложения).

Кроме того, раз мы действуем Ad-hoc - понадобилось приложение, скачали, работаем - можно сразу выключить в форме лишнее из соображений, что мы эти поля использовать не будем, чтоб не оказалось, что кто-то что-то туда всё таки забил.

Централизованное управление учетными данными

Есть решения, которые позволяют централизованно заводить учетные данные для пользователях в десяти системах по некоторому сценарию. Предположим берут сотрудника абонентской службы и делают ему учетку в системах X, Y и Z.

Нет решений, которые позволяли бы централизованно распространять эти учетные данные таким образом, чтоб сотрудник войдя в браузере в систему X или Y не вводил свои пароли для X или для Y. Если уж у нас Enterprise Browser, то почему бы не возложить взятие паролей из центрального хранилища и их ввод на него? Пусть в самом браузере пользователь авторизуется один раз либо как пользователь AD либо иным способом, которому мы доверяем.

Кроме того, можно было бы избавиться от хранения паролей в браузере на ПК и оставить их только в центральном хранилище.

Кастомизация UI без изменения приложений

Да, об этом я написал в требованиях по интеграции. Можно это считать просто поддержанием корпоративного стиля. Но раз модель DOM доступна браузеру, причем как до так и после выполнения всех скриптов, почему бы не позволить её изменять или хотя бы накладывать стили на используемые приложения централизованно?

Технологии

Самое интересное, что технологии уже есть. На серверной стороне доступны любые варианты. На клиентской есть Chromium, есть возможность встраивать IE, есть WebKit.