+1 к автору данного комментария. Планируется ли описание примера внедрения MSA в Райфе? Проблемы, с которыми сталкивается команда в целом и в инфраструктуре банка(релизное управление, сеть, сервера, мониторинг, логирование...)? Существуют ли реальные позитивные стороны данного архитектурного веяния?
vadimpl, шаблоны на пополнение с внешних карт очень скоро появятся в МБ. А пока мы его делаем, Вы можете воспользоваться ИБ — там шаблоны отлично работают. Приносим извинения за неудобства.
В Raiffeisen Online уже давно существует возможность входа по смс. Эта функция по умолчанию выключена, так как не всем пользователям нравится совершать дополнительные действия. Однако, ее можно включить через настройки.
Основные причины почему не выбрали Liferay и портальные технологии я описал в статье.
Я не говорю, что это «ужасная поделка» и бежать от нее надо не оглядываясь)
Нам показалось, что в нашем случае она мало подходит и добавит больше проблем, чем преимуществ. Почему смотрели именно Liferay, а не JBoss'овский портал я сейчас уже не вспомню.
А вот высоконагруженные системы с претензией на современный дизайн, выполненные на Liferay, я бы посмотрел.
Ошибки мобильного приложения исправляются, сейчас, возможно, не с той скоростью, с которой бы нам хотелось. В том числе и поэтому поддержка новых продукты банка идет с некоторой задержкой
Требования к символам пароля связаны с проблемой поддержания консистентности данных между старой и новой платформой. Как только у нас останется в эксплуатации только новая платформа, так нам сразу станет гораздо проще поддерживать решение, а пользователям им пользоваться.
Спасибо за отзыв!
По пожеланиям:
2. Подтвержденные шаблоны подтверждаются одноразовым паролем один раз. После этого для оплаты подтверждения паролем не требуется. Мы лишь сделали небольшую защиту пользователей от самих же себя с помощью подтверждения операции еще одной кнопкой, чтобы пользователь не совершал платежей по ошибке, например, если промахнулся мимо нужного шаблона. Платежи у клиентов настроены на разные суммы: у одного это может быть пополнение на 50 рублей, а у другого — на 50 000 рублей. Мы сами попадались в ловушку сверхбыстрых платежей на этапе пилотирования функционала внутри команды.
3. Соглашусь, что реклама всегда преимущественно раздражает, чем радует. Но у бизнеса тоже есть свои потребности, которые требуется удовлетворять. Мы подумаем, как сделать эту рекламу более полезной и менее назойливой.
4. Мы работаем над оптимизацией скорости работы.
По претензиям:
Это известный нам дефект, мы работаем над его устранением
Мобильное приложение обладает возможностями, в которых задействованы как камера (оплата платежек ряда организаций по штрих/QR-коду), так и контакты (подстановка номера телефона из списка контактов для пополнения баланса через оплату услуг). Службы определения местоположения используются для геофенсинга — функциональности по предложениям от партнеров банка по скидкам в зависимости от близости точки, в которой эту скидку можно получить.
Мы знаем об этой проблеме и работаем над ее устранением.
Подобная функциональность была в R-Connect, но мы ее оттуда удалили.
По этой задаче даже были архитектурные споры о том, кто должен это считать: интернет-банкинг или бэк-офис.
Могу лишь сказать, что в одном из будущих релизов мы реализуем эту возможность.
У нас реляционная БД. Проблемы с производительностью конечно же есть, поэтому мы используем локальное кеширование запросов на каждой из нод. В ближайшем будущем планируем этот кеш перенести на Memcache.
На старте проекта мы планировали иметь адаптивную верстку, но, по мере реализации, от этого отказались, так как у нас есть мобильные приложения под популярные платформы.
Сейчас у нас есть минимальное разрешение, которое мы поддерживаем и от которого проектируем наш UI.
Скорее всего, устройство, с которого вы используете Raiffeisen Online, обладает меньшим разрешением экрана, но возможно и другое. Если вы напишете разрешение монитора, которое у вас выставлено, либо название устройства, то станет более понятно в чем может быть проблема
Изменять логику настройкой и изменять логику программированием — разные вещи. Опыт коллег показывает, что даже если ставишь коробку и пытаешься что-то там кастомизировать самостоятельно, то рядом с коробкой вырастает собственное решение. Это если не рассматривать вопрос лицензий и исходного кода, который не всегда доступен.
Кастомизация силами вендора долго, дорого и непрозрачно. Также нет гарантии, что твою уникальную идею/функциональность не растиражируют на остальной рынок. Все это, безусловно, можно решать договорным путем, но это, опять-таки, не добавляет удобства.
Суммарно команда выросла с 30-ти до 50-ти человек. Это вся команда, включая бизнес-владельцев и AppSupport. Закрывали преимущественно IT-позиции: аналитиков, разработчиков, тестировщиков. Уровень позиций был разный: от junior до senior. Позиции выше на рынке найти практически нереально, поэтому все ведущие позиции у нас занимают ребята, которые выросли внутри команды.
Мобильное приложение нативное. Кросс-платформенные технологии вроде Cordova или Titanium, конечно, заслуживают уважения и интереса, но пока еще не дотягивают по достоинствам до нативного приложения. Особенно, если мы можем себе позволить разработчиков под популярные платформы.
Текущее мобильное приложение пока еще пользуется старой инфраструктурой и ходит на SOAP-сервисы, отдельные как от R-Connect, так и от Raifeisen Online. Новое приложение, по архитектурной задумке, будет использовать те же REST-сервисы, что и Raiffeisen Online.
Попробую неофициально ответить за коллег.
ЭЦП априори более безопасный способ подтверждения операций, но из-за этого менее удобный, особенно, в российских реалиях. Чтобы хоть как-то приблизить подтверждение операций с помощью SMS у нас происходит проверка IMSI. И Yota был одним из тех операторов, по которым мы не могли получить этот идентификатор. Я бы рекомендовал времени от времени проверять возможность переключения с ЭЦП на SMS с yota'вским номером, скорее всего это либо уже доступно, либо станет доступно в ближайшем будущем.
Можно поступить намного проще, если вы индивидуальный предприниматель, так как не так давно в Raiffeisen Online стали доступны операции по счетам ИП.
А про скорость обработки платежей в Банке мне к комментарию Alexxhn добавить нечего. На упрощенном уровне это примерно так и выглядит. Если интересно чуть более подробно посмотреть на стандартные банковские проблемы, рекомендую статью моего коллеги aBozhiev(https://habrahabr.ru/company/raiffeisenbank/blog/334242/)
Вопрос, на самом деле, в том, что использовать в качестве хранилища данных, с которым должны работать ноды логики. Можно использовать ту же самую БД, что и для хранения операционных данных. Однако, здесь встает вопрос о скорости исполнения операций чтения/записи. Поэтому сообщество обычно рассматривает более быстродействующие варианты: in-memory data grid или distrubuted cache. То есть что-то, что позволяет обрабатывать запросы на получение данных гораздо быстрее, чем стандартная корпоративная СУБД.
Мы используем Memcache для session replication стандартных веб-сессий. Остальные данные записываются в БД.
Я не говорю, что это «ужасная поделка» и бежать от нее надо не оглядываясь)
Нам показалось, что в нашем случае она мало подходит и добавит больше проблем, чем преимуществ. Почему смотрели именно Liferay, а не JBoss'овский портал я сейчас уже не вспомню.
А вот высоконагруженные системы с претензией на современный дизайн, выполненные на Liferay, я бы посмотрел.
По пожеланиям:
2. Подтвержденные шаблоны подтверждаются одноразовым паролем один раз. После этого для оплаты подтверждения паролем не требуется. Мы лишь сделали небольшую защиту пользователей от самих же себя с помощью подтверждения операции еще одной кнопкой, чтобы пользователь не совершал платежей по ошибке, например, если промахнулся мимо нужного шаблона. Платежи у клиентов настроены на разные суммы: у одного это может быть пополнение на 50 рублей, а у другого — на 50 000 рублей. Мы сами попадались в ловушку сверхбыстрых платежей на этапе пилотирования функционала внутри команды.
3. Соглашусь, что реклама всегда преимущественно раздражает, чем радует. Но у бизнеса тоже есть свои потребности, которые требуется удовлетворять. Мы подумаем, как сделать эту рекламу более полезной и менее назойливой.
4. Мы работаем над оптимизацией скорости работы.
По претензиям:
По этой задаче даже были архитектурные споры о том, кто должен это считать: интернет-банкинг или бэк-офис.
Могу лишь сказать, что в одном из будущих релизов мы реализуем эту возможность.
Сейчас у нас есть минимальное разрешение, которое мы поддерживаем и от которого проектируем наш UI.
Скорее всего, устройство, с которого вы используете Raiffeisen Online, обладает меньшим разрешением экрана, но возможно и другое. Если вы напишете разрешение монитора, которое у вас выставлено, либо название устройства, то станет более понятно в чем может быть проблема
Кастомизация силами вендора долго, дорого и непрозрачно. Также нет гарантии, что твою уникальную идею/функциональность не растиражируют на остальной рынок. Все это, безусловно, можно решать договорным путем, но это, опять-таки, не добавляет удобства.
ЭЦП априори более безопасный способ подтверждения операций, но из-за этого менее удобный, особенно, в российских реалиях. Чтобы хоть как-то приблизить подтверждение операций с помощью SMS у нас происходит проверка IMSI. И Yota был одним из тех операторов, по которым мы не могли получить этот идентификатор. Я бы рекомендовал времени от времени проверять возможность переключения с ЭЦП на SMS с yota'вским номером, скорее всего это либо уже доступно, либо станет доступно в ближайшем будущем.
А про скорость обработки платежей в Банке мне к комментарию Alexxhn добавить нечего. На упрощенном уровне это примерно так и выглядит. Если интересно чуть более подробно посмотреть на стандартные банковские проблемы, рекомендую статью моего коллеги aBozhiev(https://habrahabr.ru/company/raiffeisenbank/blog/334242/)
Мы используем Memcache для session replication стандартных веб-сессий. Остальные данные записываются в БД.