Сбербанк фреймворк использует какой

Обновлено: 19.04.2024

Сбербанк работает по Agile. Точнее по Sbergile. Но даже опытные специалисты не всегда улавливают разницу, а новички вообще склонны впадать в ступор. Мы попросили Agile-коучей Сбербанка Анну Родионову и Максима Зотова на пальцах объяснить, что все это значит и зачем нужно.

Много лет сфера IT спокойно жила без Agile. Но со временем программ стало больше, кодовые базы сложнее, пользователи избирательнее, а мир стал меняться так быстро, что цикл разработки в несколько лет перестал быть актуальным. Поэтому в 2001 году был принят манифест гибкой разработки. Он описывает ценности и принципы, которыми руководствуются команды и люди в своей работе.

Agile не включает методов, советов, описаний или точно определенных процессов и ролей. В Agile-манифесте всего 4 ценности и 12 принципов.

Ценности звучат так:

  • Люди и взаимодействие важнее процессов и инструментов
  • Работающий продукт важнее исчерпывающей документации
  • Сотрудничество с заказчиком важнее согласования условий контракта
  • Готовность к изменениям важнее следования первоначальному плану

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

C Agile немного разобрались. Теперь давайте о Sbergile.

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

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

То есть фреймворк — это свод правил, договоренностей и методик, по которым взаимодействуют люди и команды. В отличии от Agile в Sbergile гораздо больше описаний, советов, рекомендаций, процессов и инструментов. Но каждый шаг они не описывают — иначе получился бы многотомник вроде Оксфордского словаря.

Agile-трансформация Сбербанка — одна из самых масштабных в мире, и она была постепенной. В 2016 году первые 600 человек начали работать по Agile. Специально для Сбербанка был разработан свой фреймворк работы — Sbergile. Он основывается на ценностях и принципах Agile, дополненных правилами, которые описывают основные моменты взаимодействия, синхронизации и сотрудничества.

За основу был взят известный фреймворк работы команды — Scrum. О нем мы расскажем в следующий раз, пока можно посмотреть описание.

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

Фреймворк Sbergile развивается с учетом пожеланий сотрудников и отражает изменения в банке, в мире, технологиях и на рынке. С 2016 года количество сотрудников, работающих в соответствии с Agile-принципами, выросло с 600 человек до 25 000. Это позволяет банку выпускать продукты быстрее, делать их более клиентоориентированными и быть хорошим работодателем.

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

И ещё раз коротко: Agile — это общие рекомендации, Sbergile — конкретные правила, основывающиеся на этих рекомендациях.

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

Что объединяет эти идеи, и что это значит? Люди стали ценить свое время выше денег, которые они зарабатывают на работе. При этом необязательно иметь какую-то совсем уникальную идею, достаточно уметь делать что-то лучше других или иметь некоторую изюминку.

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


И сегодня в нашем посте Николай Надоричев, лидер front-end разработки Программы «Единая фронтальная система» Сбербанка, расскажет о своем видении стартапов, о распространенных ошибках и о том, как с помощью технологии React создать приложение за один вечер.

Подходы к разработке

Что мы знаем о разработке стартапа? Она состоит из нескольких этапов:

  1. Proof of concept
  2. Получение инвестиций
  3. Сбор команды
  4. Разработка MVP
  5. Презентация инвестору и получение нового раунда финансирования

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

Причины неудач

Мы придумали стартап, он классный, но не выстрелил. Почему?

Первая причина — попытка объять необъятное. Многие молодые разработчики, уверенные в своих силах, чувствуют себя супергероями. Они пытаются создать идеальное решение, но на это уходит слишком много времени.

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

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

Стек технологий

Фреймворк

У нас есть идея, теперь нужно создать приложение. С чего начать? Прежде чем перейти к выбору технологий, необходимо определиться с тем, какие технологии нам нужны.

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

  • поддержка сообществом
  • продвижение гигантами IT-индустрии
  • легкость освоения
  • зрелость технологии.

Исходя из этих соображений, мы в Программе «Единая фронтальная система» выбрали основным фреймворком для разработки React. Почему? Давайте пройдемся по всем пунктам: для React существует огромное количество написанных элементов UI, библиотек для управления состоянием приложения и других модулей. Это делает возможным не делать часть своей работы — можно просто взять готовый компонент и встроить его в приложение.

При всех преимуществах React имеет ложку дегтя в виде сложной настройки проекта. К счастью, Facebook позаботился об этом и выпустил проект Create React App. Он изначально заточен на быстрый старт проекта с переходом от идеи сразу к разработке.

О том, как создать приложение на реакте за один вечер, Николай рассказал на конференции. Смотрите видео-инструкцию.

UIKit

Позволить себе создать свой собственный уникальный набор UI-компонентов могут только компании, у которых уже есть отдельная команда для разработки UIKit'а. Известны истории, когда UIKit разрабатывается всеми продуктовыми командами совместно, но у этого подхода есть ключевой недостаток: чем больше разработчиков, тем больше мнений. И в конечном счете это приведет к тому, что каждая команда будет перетягивать одеяло на себя.

Но наша цель — выпустить MVP в короткие сроки. На просторах сети есть множество готовых решений, как платных, так и open source. Можно назвать несколько популярных:

Или Minimum Viable Product — минимально жизнеспособный продукт. Он подразумевает то, что есть некоторый минимум приложения, который обеспечивает подтверждение концепции. Его основная цель — в том, чтобы показать, что продукт имеет право на жизнь. Он не требует детальной проработки архитектуры баз данных, работе под высокой нагрузкой и красивого дизайна. Зачастую он показывает некоторую интерактивную картинку, которую можно пощупать.

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


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


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

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

О чем пойдет речь

Мы расскажем, как в мобильном и веб приложениях Сбербанк Онлайн работают платежные сценарии, а именно про API между приложениями и сервер-сайдом.


Почему фокус на API? Все просто – это фактически единственный мостик, который соединяет клиентские приложения и бэкенд. Если проект небольшой, то мы можем легко менять API и переписывать под него приложения. Но если проект масштабный (такой, как у нас), то даже небольшие изменения API требуют вовлечения большого количества ресурсов как на фронте, так и на бэкенде, и становятся очень дорогими. И второй момент – чем раньше мы зафиксировали API, тем раньше фронтальные и бэковые команды могут начинать разработку. Им просто надо будет сойтись в одну точку.

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

Специфика и мотивация

Приложения большие. Когда мы писали эту статью, приложение Сбербанк Онлайн на Android занимало около 800 000 строк кода, на iOS – 500 000 строк кода. И это только наш код, без подключаемых библиотек.

Обратная совместимость и много пользователей. MAU – 32 млн активных пользователей мобильного приложения. И если мы не сделаем обратную совместимость на уровне API, очень многим пользователям по всей стране придется качать приложения заново. Это очень нехорошо. Кстати, это одна из причин, почему у нас так много кода.

Сбербанк Онлайн разрабатывает много небольших команд. Вы, наверное, слышали про Agile в Сбербанке. Это правда, мы работаем по Agile в командах по 9 человек.

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

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

Омниканальность. Крайне важная история. Чтобы не разрабатывать бэк несколько раз – отдельно для мобильных приложений и отдельно, например, для веб-версии и банкоматов, нужно сделать так, чтобы API был максимально схожим для всех каналов (как минимум должна быть одинаковой структура ответа).

Мобильное приложение

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

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

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

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

Как делать не стали

После того как мы обозначили граничные условия, расскажем, какие существующие решения мы анализировали.

Программирование на JSON

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

Не используем описание стилей компонентов, поскольку они могут разниться от форм-фактора, платформы и даже режима работы (портретная/ландшафтная ориентация, responsive в web). Декларации стилей в конечной реализации всегда будут качественнее, ближе к реальности и корректнее работать с краевыми случаями. Кроме этого, бывает, что компоненты со схожей логикой принципиально по-разному работают на разных устройствах: например, ввод номера телефона – с телефонной книгой на мобильном устройстве и без неё в вебе.

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

Этот способ еще называется «прибить гвоздями». Смысл в том, что интерфейс приложения строится на уникальных идентификаторах объектов, которые передаются с сервера. В такой схеме любые изменения на стороне сервера приводят к переработкам клиентской части. Невозможно повторно использовать код. Сложно поддерживать.
Единственное, почему стоит выбирать такой способ на своем проекте, – уверенность на 99%, что API не будет меняться. Ну или если проект совсем небольшой и проектировать API дороже, чем быстро переделать пользовательский интерфейс под изменения в API.

Добавляем к каждому объекту признак стиля. UI приложений строим на основании этого признака. Стилей ограниченное число, поэтому появляется возможность строить интерфейс динамически. Но с увеличением функциональности UI приходится увеличивать количество стилей.
В этом варианте становится возможно управлять отображением отдельных элементов, но повышается сложность реализации связанности между разными полями. И главное – с ростом вариативности UI у вас будет постоянная необходимость расширять протокол API.

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

Web Components / React Components API

Концепция веб-компонентов, которая в том числе значительно повлияла на API компонентов React, нам подходит уже намного лучше: с одной стороны, у нас есть контроль за отображением, с другой стороны – есть возможность привязывать данные к элементам UI.
К сожалению, всё слишком сильно завязано на HTML + CSS + JS. Напрямую не используешь, но запомним – потом пригодится.

Как решили делать

UI-контейнеры

Объекты упаковываются в контейнеры, презентационную логику приложения строим на этих контейнерах. Основное преимущество – можем группировать несколько простых объектов в один контейнер. Это дает свободу в программировании UX/UI на клиенте, например, можем управлять скрытием/отображением одного поля при заполнении данных в другом. При этом базовых типов объектов – ограниченное число, и весь бизнес-транспорт реализуется на них.

Мы выбрали именно этот подход. Сначала мы опишем протокол API, а потом – как устроены фрэймворки внутри мобильных и веб-приложений.

Чтобы было понятнее, рассмотрим API на примере простого процесса, например, перевод между своими счетами. Как добираемся до точки входа, не рассматриваем – это не процесс и для этого есть свой API (о нем мы тоже как-нибудь расскажем). Итого, процесс у нас начинается с точки входа:

Транспорт данных

Для начала договоримся об основных принципах – как передаём данные. За основу возьмём самый простой подход – пары «ключ-значение». Ключом пусть будет строка из букв латинского алфавита, значение – тоже строки, но уже произвольные.

Формы для заполнения бывают сложные, с вложенными элементами и подразделами, значит, надо допускать вложенность. Можно именовать ключи в формате camelCase, но они могут быть плохо читаемым (например, в логах) или даже «портиться» в системах, нечувствительных к регистру. Нужно ввести разделитель.

Самый очевидный разделитель – точка – во многих языках используется для доступа к свойствам объекта. При неаккуратном использовании ключи с таким разделителем будут создавать словари (или объекты), в которых возможны коллизии. Например, “foo.bar” = “foobar” и “foo.bar.baz” = “foobarbaz” в javascript может повлечь перезапись свойства “bar” объекта “foo” со строки на объект. В конце концов, договорились на двоеточии: с одной стороны, явное визуальное разделение и семантическое отражение вложенности, с другой стороны, достаточно безопасно для всех используемых языков.

Что делать с повторяемыми полями? Вводим дополнительное правило: между парой разделителей могут быть либо латинские буквы, либо цифры. Получаются конструкции вида: children:5:name:first.

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

Решение: значение – либо строка, либо список строк. Так решение выглядит типовым, но в то же время накладные расходы оказываются незначительными.


Шаг – это состояние процесса. Первый шаг у нас – выбор счета списания и счета зачисления и ввод суммы.

UI на этой картинке не видно, потому что шаг – это про серверную логику, а не про презентационную. Есть два подхода к работе с шагами: можно передавать с сервера только разницу (нарастающий итог в клиентском приложении) или каждый шаг целиком (нарастающий итог на сервере).

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

Из дополнительных плюсов: при возврате к редактированию не нужно проигрывать весь сценарий или передавать дополнительный параметр “отдай всё”. При старте шага клиентское приложение сразу же получает всю нужную информацию для построения экранов.

Экраны


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

Для экранов мы ввели два правила:

  1. переход между экранами может быть только линейным, без ветвлений;
  2. переход между экранами не требует взаимодействий с бэкэндом.

UI компоненты (блоки)

UI компонент – независимый компонент, который реализует клиентскую логику и наполняет документ данными. По сути, это ассоциация между управляющей командой в протоколе и куском кода и разметки в приложении. На первом экране три компонента:

  1. Счет списания
  2. Тот же компонент для счета зачисления
  3. Сумма перевода

Поля – это атомарные компоненты, которые выступают транспортом для отдельных элементов данных и обрабатывают пользовательский ввод в случае деградации блока. Типов полей ограниченное число и все они поддерживаются на уровне фрэймворка: text, checkbox, select, multiselect.

Это значит, что любая версия приложения может отрисовать интерфейс, опираясь только на типы полей.

Поля в UI-компонентах из нашего примера:


1. Поле со ссылкой на справочник в счете списания и счете зачисления. Почему ссылка на статический справочник? Потому что счет мы выбираем из списка карт (счетов), без лишнего обращения к серверу.


2. Два отдельных поля для суммы и валюты в компоненте ввода суммы

Таким образом, формат для полей имеет такую структуру:

События

Так как приложения ничего не знают о процессе, логично, чтобы события (кнопки, которые видит пользователь) тоже были частью ответа от сервера.

События мы разделили на два типа.

1) Основные – они есть почти на каждом экране в привычных местах для пользователя. Как пример, это события «назад» и «продолжить». Первое осуществляет переход на шаг назад, а второе собирает заполненные данные с клиентской формы и отправляет их на сервер вместе с командой «Перейти на следующий шаг».


2) И специальные – для нестандартных действий, которые мы заранее спрогнозировать не можем, да и смысла закладывать их в часть движка нет, так как они редко используются.
В нашем случае на экране только основные события – «продолжить» и «назад». Они реализованы на уровне платформы.

У всех событий есть ряд атрибутов, такие как сам тип события, title и признак видимости. И никакого UI на сервер-сайде вроде размера кнопки, положения и цвета. Эта логика реализуется на фронте.

Справочники

Со справочниками все стандартно. Если он небольшой, то мы его присылаем полностью в ответе от сервера и называем статическим. Сделано это для того, чтобы минимизировать количество запросов к сервер-сайду и время отклика на действие пользователя в интерфейсе. Чтобы его отобразить в форме на экране, добавляем поле с типом – selectList, одно из свойств которого – ссылка на статический справочник.

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

Ошибки валидации на клиенте и сервере


Примерно так выглядит структура ответа:


Фрэймворки

Теперь немного о том, как с этим протоколом работают фрэймворки внутри приложений. Условно фрэймворки можно разделить на две основные части: workflow engine + обработчик UI-контейнеров. Такое разделение вызвано не только архитектурой приложений, но и организационной структурой. Движок разрабатывают и поддерживают платформенные команды, а UI-контейнеры фактически являются точками расширения и их программируют фичёвые команды. Таким образом, большему количеству команд не нужно вносить изменения в ядро.

Workflow engine

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

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

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

Как работают UI-контейнеры?

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

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

Два режима работы фрэймворка

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


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

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

Каких правил мы стараемся придерживаться при работе с UI-компонентами:

  • Поддерживать работу функционала в режиме списка простых типов полей. У любого прикладного проекта есть соблазн превратить динамический протокол в статический. Поэтому мы всех просим сначала разработать функционал на типовом UI-контейнере, а потом обогащать UX/UI добавлением кастомных контейнеров на этой модели данных. Это не только позволит в будущем обновлять процессы на старых сборках, но и автоматически поддерживает логическую целостность API.
  • Не менять модель данных (JSON) для UI-контейнера, если он уже готов (проходит финальное тестирование или уже в продакшене). Так как логика на PL жестко связана с моделью данных, её изменение сломает функционал на версиях мобильного приложения, которые не обновляются. Тем не менее, модель можно расширять при условии сохранения обратной совместимости.
  • Называть свой UI-компонент системным именем. Так как имя UI-компонента – обязательный атрибут протокола и должен быть минимум один на каждом экране, мы ввели специальное системное имя, которые реализует простой список полей.
  • Не реализовывать бизнес-логику на UI-компонентах. Логику необходимо реализовывать на сервере, почему – писали выше.

Coming soon…

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

Пишите в комментариях, что непонятно, что интересно – постараемся писать меньше, но чаще и в цель. У нас много интересных вызовов, и поэтому много материала.

Python библиотека для серверных приложений, упрощающая получение Access Token и UserInfo.

Установка

Установка через pip:

Установка из исходников через setuptools:

Использование

Необходимый импорт

Создание API-клиента

Датаклассы Consumer и Authmachine

Класс Consumer описывает параметры потребителя сервиса:

  1. client_id - Уникальный идентификатор потребителя
  2. client_secret - Пароль доступа к API
  3. client_crt - Путь к TLS сертификату (может быть None)
  4. client_pass - Пароль к TLS сертификату (может быть None)

Класс Authmachine описывает параметры сервиса аутентификации:

  1. issuer - URL-адрес, который сервис аутентификации утверждает в качестве своего идентификатора.
  2. authorization_endpoint - URL точки аутентификации
  3. token_endpoint - URL точки получения ID token, access token
  4. userinfo_endpoint - URL точки получения пользовательских данных

Адреса для получения ID token, access token перечислены в Шлюзы вызова API, для получения пользовательских данных в Шлюзы вызова API

Классы PKCEData и PKCEMethod

Вспомогательные классы для повышения защищенности передачи данных пользователя с использованием алгоритма PKCE.

Client и AuthorizationResponse

Абстрактный класс Client реализует основные методы для взаимодействия с сервисом аутентификации и получения пользовательских данных:

Метод get_authorization_url

Формирование URL адреса аутентификации пользователя. Принимает следующие параметры:

  1. scope - Запрашиваемые наборы данных
  2. redirect_uri - URL возврата к потребителю
  3. pkce - PKCE верификатор (может быть None)

Метод get_userinfo

Получение данных пользователя. Возвращаемое значение - словарь с полученными параметрами. Принимает следующие параметры:

  1. redirect_url : URL возврата к потребителю
  2. code_verifier : PKCE верификатор (может быть None)

Полное описание параметров ответа на запрос access token, ID token можно найти в Параметры ответа.

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

Абстрактный метод get_authorization_response

Преобразование запроса с полученным пользователем AuthCode в экземпляр AuthorizationResponse. Не принимает параметров.

Ошибки

Все исключения, генерируемые библиотекой являются наследниками класса SberAPIException

AuthException

Исключение бросается при получении обратного редиректа с непустым параметром error

APIErrorResponse

Исключение бросается при неуспешном вызове конечных точек token и userinfo

Логгирование

Класс Client принимает не обязательный параметр logger в конструкторе. В случае его отсутствия используется стандартный логгер.

Пример

Полный пример с использованием фреймворка Flask содержится в исходном коде библиотеки.

Получение адреса аутентификации пользователя:

Получение данных пользователя после его успешной аутентификации::

Совместно с

  • 6 августа 2020
  • 10 мин
  • 12 659

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

SberBusinessAPI (application programming interface, интерфейс программирования приложений) — это технология прямой интеграции с банком, которая позволяет мгновенно обмениваться платёжными данными с интернет-банком, автоматически авторизовываться в сервисах экосистемы Сбербанк Бизнес Онлайн, а также предоставляет широкий спектр возможностей партнёрского взаимодействия с банком.

Как работает SberBusinessAPI

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




Это решение позволяет значительно упростить и оптимизировать бизнес-процессы компании. Приведу пример: чтобы сотрудники могли получить зарплату, бухгалтерии приходится целый день формировать реестры, сохранять их в определённом формате и выгружать в приложение «Клиент-Банк». С помощью SberBusinessAPI возможно провести синхронизацию с банком и направлять на исполнение зарплатные реестры, не импортируя их из учётной системы. Это экономит рабочее время, снижает вероятность ошибок .

Сергей Паршиков ,

управляющий директор, дивизион «Цифровой корпоративный банк» Сбербанка

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


Бесшовная авторизация. SberBusinessAPI предоставляет корпоративным клиентам возможность пользоваться экосистемой Сбербанка (более 40 продуктов, сервисов и услуг для предпринимателей, объединённых единым интерфейсом) с помощью механизма бесшовной авторизации SberBusinessID.


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


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


Методы получения информации по счетам и операциям, что позволяет пользователям предлагать инновационные продукты и сервисы на основе информации о движении денежных средств, например, с помощью такого сервиса экосистемы, как «Бизнес-аналитика» .


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


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


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


Кредит в корзине — дополнительный метод оплаты, альтернатива отсрочки, которая используется в качестве инструмента увеличения воронки продаж.


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

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

Для того чтобы использовать SberBusinessAPI, существенных доработок учётной системы предприятия не требуется: технология Сбербанка не предъявляет каких-то специфичных требований к инфраструктуре или программному обеспечению. Она предоставляет внешнему разработчику возможность оценить функционал SberBusinessAPI без написания кода, определить масштаб предстоящей работы и понять логику программы. С помощью «песочницы» для тестовых испытаний можно получить первые положительные результаты всего за час. Несмотря на кажущуюся простоту, SberBusinessAPI обладает надёжной многоуровневой защитой, соответствующей требованиям регуляторов и российского законодательства.

Автор статьи

Куприянов Денис Юрьевич

Куприянов Денис Юрьевич

Юрист частного права

Страница автора

Читайте также: