ОБЛАСТЬ ТЕХНИКИ

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

УРОВЕНЬ ТЕХНИКИ

Из уровня техники известно наиболее близкое техническое решение, раскрытое в источнике информации US 10,331 ,416 В2, опубликованное 25.06.2019 г. Суть решения заключается в том, что в интернет-сервис встраивается приложение, позволяющее пользователям интернет-сервиса самостоятельно настраивать взаимодействие интернет-сервиса с другими интернет-сервисами путём указания всех деталей их взаимодействия.

Отличие данного решение от предлагаемого решения состоит в том, что данное решение описывает непосредственно встраивание одного приложения в другое. В то время как предлагаемое решение описывает методы и способы подготовки приложения (или приложений) для встраивания, не рассматривая сам механизм встраивания. Таким образом, основным недостатком данного решения является невозможность его адаптации или настройки под нужды того сервиса, куда происходит встраивание. Например, будут доступны сервисы, интеграция с которыми не имеет смысла с точки зрения пользователя, или сервисы-конкуренты. Другим недостатком такого решения является его сложность для пользователя и возможное возникновение ошибок при взаимодействии интернет-сервисов из-за неверной настройки. То есть эффективность использования такого решения зависит от субъективных качеств оператора или сотрудника, который данным решением воспользуется. Также к недостаткам можно отнести встраивание сервиса целиком, без возможности встраивания отдельных его частей.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ Технической задачей, на решение которой направлено заявленное техническое решение, является создания встраиваемого приложения для интеграции сетевого сервиса со множеством других сетевых сервисов способом, максимально подходящим для конкретного сервиса с точки зрения предметной области, удобства пользователей и финансовых взаиморасчетов между сервисами. В связи с этим предложен способ реализации приложения для создания встраиваемых приложений для интеграции сетевых сервисов, который охарактеризован в независимом пункте формулы. Дополнительные варианты реализации настоящего изобретения представлены в зависимых пунктах изобретения.

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

Заявленный результат достигается за счет осуществления компьютернореализуемого способа реализации приложения для создания встраиваемых приложений для интеграции сетевых сервисов, содержащий этапы, на которых: создают интеграционное приложение; задают заранее заданные настройки для интеграции интеграционного приложения или его части с сетевым сервисом; применяют заранее заданные настройки для интеграции интеграционного приложения или его части с сетевым- сервисом; в результате применения заранее заданных настроек для интеграции интеграционного приложения или его части с сетевым сервисом формируется код для интеграции интеграционного приложения или его части с сетевым сервисом и/или набор интерфейсов для программного обращения для взаимодействия сетевого сервиса с интегрированным приложением, причем результат настроек доступен в момент их выполнения; осуществляют интеграцию интеграционного приложения или его части с сетевым сервисом.

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

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

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

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

ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг. 1 схема взаимодействия сетевых сервисов по сети напрямую между собой.

Фиг. 2 схема взаимодействия сетевых сервисов по сети с помощью интеграционного приложения.

Фиг. 3 схема встраивания приложения при выборе настройки единого интерфейса приложения.

Фиг. 4 схема встраивания приложения при выборе настройки множественных интерфейсов приложения.

Фиг. 5 примерный вариант реализации интерфейса создания встраиваемых приложений на базе веб-приложения, экран выбора настроек.

Фиг. 6 примерный вариант реализации интерфейса создания встраиваемых приложений на базе веб-приложения, экран получения сформированного кода для встраивания и описания спецификации программного интерфейса взаимодействия (API).

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

ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

Под сетевым сервисом (1) понимается интерфейс между потребителем и поставщиком услуг, выполненный с возможностью взаимодействия посредством локальных или глобальных сетей, в том числе, сети Интернет (2). В настоящий момент существует большое количество сетевых сервисов, решающих различные задачи пользователей. Однако, каждый отдельный сервис часто не способен решить все задачи пользователя, которые могут относиться к различным предметным областям, поэтому перед пользователем встаёт вопрос использования одновременно нескольких сервисов. Часто требуется, чтобы различные сетевые сервисы использовали одни и те же данные пользователя, либо один сетевой сервис использовал результаты работы другого сетевого сервиса, то есть перед пользователем встаёт задача автоматической или автоматизированной передачи данных между сетевыми сервисами.

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

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

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

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

Далее задают настройки для интеграции интеграционного приложения или его части с сетевым сервисом. Под встраиванием части интеграционного приложения понимается ограничение функционала интеграционного приложения для встраивания. То есть не всё, что умеет интеграционное приложение, доступно для встраивания. Допустим, часть функций интеграционного приложения не имеет смысла использовать для конкретного сетевого сервиса, или же сетевой сервис не может встраивать часть интеграционного приложения, связанную со взаимодействием с конкурирующими сервисами.

Ниже будут описаны возможные варианты настроек встраиваемого приложения, которые не ограничиваются данными настройками.

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

Одна из возможных настроек позволяет указать способ настройки интеграций с подключаемыми сервисами. С помощью данного выбора во встраиваемом интеграционном приложении можно либо предоставлять пользователю все возможности по самостоятельной настройке интеграции двух или более сервисов с указанием им всех деталей взаимодействия, либо использовать заранее преднастроенные шаблоны интеграции сетевых сервисов, применение которых снижает требования к квалификации пользователя, осуществляющего интеграцию. Под предварительно настроенными шаблонами понимаются заранее заданные наборы настроек по осуществлению интеграции между сервисами, в том числе, такие настройки, как: сущности (наборы данных), которые передаются между сервисами, периодичность передачи данных, правила преобразования данных между сервисами (например, фильтрация части данных, сопоставление полей данных в разных сервисах), правила обработки повторно переданных данных и любые другие возможные настройки интеграции двух или более сервисов, которые позволяет осуществлять интеграционное приложение. Шаблоны таких интеграций могут быть либо преднастроены заранее сотрудниками или пользователями интеграционного сервиса, а могут являться дополнительной настройкой встраиваемого приложения и разрабатываться конкретно для целей использования в нём.

Одна из возможных настроек позволяет управлять внешним видом, дизайном и стилистикой встраиваемого приложения. С её помощью можно придать встраиваемому интеграционному приложению внешний вид, схожий с внешним видом сервиса, куда осуществляется встраивание. В рамках данной настройки может предоставляться управление брендированием встраиваемого интеграционного приложения, например, можно полностью отключить брендирование интеграционного приложения и использовать элементы и логотипы брендирования основного сетевого сервиса. В рамках данной настройки может предоставляться управление количеством интерфейсных элементов или окон отображения, которые будут встроены: при одном варианте данной настройки весь интерфейс встраиваемого интеграционного приложения (4) может показываться в рамках одного окна интерфейса (Фиг.З), при другом варианте данной настройки может создаваться множество доступных для встраивания окон интерфейса или даже отдельных встраиваемых приложений - по одному на каждый сетевой сервис, доступный для интеграции с основным сетевым сервисом (Фиг.4). В случае веб-приложений, например, окна интерфейса встраиваемого приложения могут быть реализованы с помощью инструмента iframe, поддерживаемого большинством современных браузеров. При этом данная настройка позволит выбирать между единым iframe’oM на всё интеграционное приложение или между множеством небольших iframe’oB на отдельные разделы или подключаемые сервисы интеграционного приложения.

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

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

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

3) сетевой сервис, куда осуществляется встраивание, никак не учитывает расходы пользователей, связанные с использованием встраиваемого интеграционного решения.

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

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

В результате всех произведённых настроек или части из них формируется и выдается программный код для встраивания в код сетевого сервиса и/или набор интерфейсов для программного обращения (API, от англ. Application Programming Interface) для взаимодействия сетевого сервиса со встраиваемым приложением (Фиг.7).

Под наборами интерфейсов понимаются определённые процедуры и регламенты, с помощью которых один сервис может обращаться к другому сервису без участия человека. В контексте данной заявки, набор интерфейсов для программного обращения является вариантом встраивания приложения, когда визуальный интерфейс реализуется самим сетевым сервисом, а работа настройка интеграции осуществляется посредством обращения к методам API интеграционного приложения. Методы API появляются в результате создания и настройки встраиваемого интеграционного приложения, при этом они сопровождаются спецификацией, описывающей созданные API-методы, с указанием адресов и способов вызовов методов API, названий методов API, состава и формата передаваемых в методы API данных, формата возвращаемых методами API данных, возможные коды и сообщения об ошибочных вызовах методов API и других параметров АР1-взаимодействия, зависящих от выбранных средств реализации взаимодействия. В качестве примера методов API можно привести следующие:

• Метод API создан ия/удален ия пользователя в интеграционном приложении для привязки контекста настроек встраиваемого интеграционного приложения к контексту сетевого сервиса.

• Метод API управления тарифными планами пользователей для целей обеспечения финансовых взаиморасчетов между сетевым сервисом и встраиваемым интеграционным приложением.

• Метод API включения/выключения интеграции между сетевым сервисом и сторонним сетевым сервисом в рамках возможностей, предоставляемых интеграционным приложением.

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

Далее, созданное и настроенное интеграционное приложение или его часть можно встраивать в сетевой сервис. При этом механизм встраивания зависит от выбранных при создании приложения настроек. Если, например, выбрано встраивание с помощью программного кода для отображения интерфейса встраиваемого приложения в iframe, то сотрудникам сетевого сервиса необходимо встроить программный код вызова iframe в код отображения своего сетевого сервиса. Также возможно осуществление автоматического встраивания при поддержке сетевым сервисом системы публичных документированных плагинов или публичного доступного маркетплейса приложений. То есть когда есть заранее публично оговоренный формат встраиваемого приложения произвольного назначения, а интеграционное приложение создают в описанном выше формате.

Например, после встраивания сформированного программного кода в сетевой сервис, при работе пользователя в сетевом сервисе осуществляется вызов программного кода, который может быть реализован на отдельной странице личного кабинета пользователя данного сервиса с заголовком “Интеграции”. Данный вызов программного кода приводит к работе встраиваемого интеграционного приложения. При этом на данной странице будет отображаться визуальный интерфейс встраиваемого приложения внутри iframe.

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

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

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

Фиг. 8 далее будет представлена общая схема вычислительного устройства (800), обеспечивающего обработку данных, необходимую для реализации заявленного решения.

В общем случае устройство (800) содержит такие компоненты, как: один или более процессоров (801), по меньшей мере одну память (802), средство хранения данных (803), интерфейсы ввода/вывода (804), средство В/В (805), средства сетевого взаимодействия (806).

Процессор (801) устройства выполняет основные вычислительные операции, необходимые для функционирования устройства (800) или функциональности одного или более его компонентов. Процессор (801) исполняет необходимые машиночитаемые команды, содержащиеся в оперативной памяти (802).

Память (802), как правило, выполнена в виде ОЗУ и содержит необходимую программную логику, обеспечивающую требуемый функционал.

Средство хранения данных (803) может выполняться в виде HDD, SSD дисков, рейд массива, сетевого хранилища, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средство (803) позволяет выполнять долгосрочное хранение различного вида информации, например, вышеупомянутых файлов с наборами данных пользователей, базы данных, содержащих записи измеренных для каждого пользователя временных интервалов, идентификаторов пользователей и т.п.

Интерфейсы (804) представляют собой стандартные средства для подключения и работы с серверной частью, например, USB, RS232, RJ45, LPT, СОМ, HDMI, PS/2, Lightning, FireWire и т.п.

Выбор интерфейсов (804) зависит от конкретного исполнения устройства (800), которое может представлять собой персональный компьютер, мейнфрейм, серверный кластер, тонкий клиент, смартфон, ноутбук и т.п.

В качестве средств В/В данных (805) в любом воплощении системы, реализующей описываемый способ, должна использоваться клавиатура. Аппаратное исполнение клавиатуры может быть любым известным: это может быть, как встроенная клавиатура, используемая на ноутбуке или нетбуке, так и обособленное устройство, подключенное к настольному компьютеру, серверу или иному компьютерному устройству. Подключение при этом может быть, как проводным, при котором соединительный кабель клавиатуры подключен к порту PS/2 или USB, расположенному на системном блоке настольного компьютера, так и беспроводным, при котором клавиатура осуществляет обмен данными по каналу беспроводной связи, например, радиоканалу, с базовой станцией, которая, в свою очередь, непосредственно подключена к системному блоку, например, к одному из USB-портов. Помимо клавиатуры, в составе средств В/В данных также может использоваться: джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.

Средства сетевого взаимодействия (806) выбираются из устройства, обеспечивающий сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi-Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п. С помощью средств (805) обеспечивается организация обмена данными по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.

Компоненты устройства (800) сопряжены посредством общей шины передачи данных (810).

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