Сервис-ориентированная архитектура является самым современным и сильным участником в мировой архитектуре программного обеспечения со всеми его преимуществами, которые реализуются, если принятый метод организации правилен. Модуль процесса FLEXCUBE BPEL является расширением SOA ведущей мировой АБС FLEXCUBE Процессинговый модуль FLEXCUBE BPEL предоставляет решение для основных функций банка, основываясь на рабочих процессах и поставленных задачах.
Уважаемый, 44 летний банк на Тайвань, обслуживающих как учреждения, так и розничный бизнес, стал первым банком, который выбрал модуль процессов FLEXCUBE BPEL, чтобы сделать «SOA способной» свою экосистему ПО. Основным требованием было обеспечить бизнес процесс SOA, основанный на решении конкретной задачи, удовлетворяя требования финансирования торговой деятельности. Задача заключалась в совмещении возможностей существующей системы AS400 (2-х уровневое решение) при использовании модуля процессов FLEXCUBE BPEL, который является “n-уровневым» решением на основе технологии Java. Ожидания от эффективности работы были огромными и компонент BPEL сервисной инфраструктуры Oracle SOA Suite 10g, на которой была построена инфраструктура FLEXCUBE BPEL, был все ещё в своей ранней стадии развития. Компонент Oracle BPEL обеспечиваел интерфейс прикладного программирования (Application Programming Interface API), который используется инфраструктурой BPEL для FLEXCUBE.
FLEXCUBE BPEL модуль обеспечивает рабочий процесс и решения на основании поставленной задачи. Пользовательский интерфейс этого модуля позволяет пользователю просматривать задачи, возложенные на него / нее. Эти задачи отображаются для пользователя и группируются на основе различных признаков задачи. Эти группы называются очередями (queues). Очереди также показывают количество задач под ними. Для этого банка, количество очередей было огромным (так как они требовали копирования их существующей системы). Чтобы учесть все очереди, API выполняет столько запросов к базе данных, сколько имеется очередей, и очереди просматриваются пользователем несколько раз, в зависимости от его / ее требований. Во время приемочных и нагрузочных испытаний, проблемы с производительностью всплыли в этой части API. Эти вопросы возникли отчасти из-за недостатков API, а частично из-за неправильного использования API для выполнения требований данного банка. В данный момент в проекте было невозможно устранить зависимости от API в инфраструктуре. Проблема была решена путем изменения инфраструктуры, чтобы избежать использования проблемных областей API без ущерба для зависимостей ядра функциональности API. Например, одна из областей, которая являлась проблемной, была выполнение запросов к базе данных BPEL при помощи API, который отнимает много времени. Этот недостаток API был преодолен при достижении ступени, когда запрос строится API, а затем этот запрос обращается непосредственно к базе данных, не используя API.
Это решения удовлетворило бизнес-требования и помогло достичь критериев оценки эффективности работы в соответствии с пожеланиями заказчика.
English
日本語
Русский