Разрушить хранилища данных с помощью мобильных микросервисов

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

Разработано для настольной эры

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

Предназначен для бункера данных

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

Предназначен для письменного стола, а не для кармана

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

Рассчитан на некоторое время, а не в реальном времени

Мы взаимодействуем с API в коротких, насыщенных сессиях — поэтому нам нужно спроектировать наш API для этого нового мира мобильных устройств. В предыдущей публикации блога [1] мы установили важность создания связных, специфичных для мобильных устройств API, которые сокращают полезные нагрузки и объединяют несколько ответов API, но иногда этого недостаточно.
Возможно, нам придется подумать о создании API, который может реагировать в реальном времени на изменения данных через постоянно открытое соединение, такое как веб-сокеты, или использовать push-API для обновления мобильного пользователя некоторой новой информацией, даже когда устройство спит в кармане.
Это далеко от функциональности, которую предоставляют эти монолитные бункерные приложения.

Предназначен для тупых датчиков, а не для умных

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

Разработано, чтобы быть дорогим

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

Установка информации бесплатно

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

Путешествующий продавец

Помните нашего торговца зонтиками для путешествий Microservices for Mobile Fame? В этом предыдущем посте мы обнаружили, что использование микросервисной архитектуры значительно ускоряет время отклика в сетях с потерями.

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

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

Мы также собираемся использовать сенсорные возможности устройства, которые мы не получим с бумагой, для создания мобильного приложения, которое собирает место, где будут храниться скворечники.
Наконец, мы собираемся использовать некоторые модули Node.js с открытым исходным кодом для извлечения данных о клиентах из Salesforce и информации о продукте из списка Sharepoint и использовать их для заполнения данных в мобильном приложении.

Постоянные разъемы

Я собираюсь использовать пробную учетную запись Salesforce и Sharepoint 365 для сегодняшней интеграции. Salesforce будет содержать учетные записи, с которыми мы будем связывать наши заказы.
У SharePoint будет список, каждый элемент которого представляет информацию о продукте.
Перед тем как поставить эти микросервисы, мне нужно собрать некоторую информацию о моих экземплярах — имена пользователей, пароли и связанные URL-адреса служб.

Я использовал разъем Red Hat Mobile Sharepoint и Salesforce . Они предоставляют обнаруживаемые интерфейсы для этих сервисов на нашей платформе, но также могут использоваться автономно.

Данные о наших продуктах в SalesForce

Вы также можете написать свои собственные соединители — мы использовали модули Sharepointer и Node Salesforce в наших соединителях. Какой бы подход вы ни выбрали, знайте, что эти соединительные микросервисы должны многократно использоваться в любых будущих проектах, которым может потребоваться получение данных из Sharepoint или Salesforce.

Стать владельцем наших данных

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

Мы просто собираемся представить интерфейс Create (т.е. POST / orders) и List (т.е. GET / orders) для этой службы. Мы уже установили соединение с БД .

Фрагмент кода:

const COLLECTION = 'orders';
orders.get('/', function(req, res) {
  var collection = db.collection(COLLECTION);
  collection.find().toArray(function(err, results){
    if (err) {
      return res.status(500).json(err);
    }
    return res.json(results);
  });
});

orders.post('/', function(req, res) {
  var collection = db.collection(COLLECTION);
  collection.insert([req.body], function(err) {
    if (err) {
      return res.status(500).json(err);
    }
    return res.json(req.body);
  });
});

api.use(function(req, res, next){
  var cacheKey = _.last(req.path.split('/'));
  return fh.cache({ act : 'load', key : cacheKey }, function(err, cacheRes){
    if (!err && cacheRes){
      cacheRes = JSON.parse(cacheRes);
      return res.json(cacheRes)
    }
    return next();
  });
});

var async = require(‘async’);
// Load both our Accounts list and our Products list from our cache
async.parallel({
  accounts : async.apply(fh.cache, { act : 'load', key : 'accounts' }),
  products : async.apply(fh.cache, { act : 'load', key : 'products' })
}, function(err, cacheResults){
  // We store stringified values in the cache. 
  //  JSON.parse them & we have a full list of accounts and products 
  var accounts = JSON.parse(cacheResults.accounts),
  products = JSON.parse(cacheResults.products);

  //TODO: Now we just need to find the relevant account and product, 
  // and include this in our response
});