Сервер JPOS Q2 в качестве маршрутизатора платежного шлюза
- Насколько мне известно, мы можем получить сообщение ISO8583 от одного хоста / коммутатора и выполнить некоторую обработку и переслать сообщение на другой хост / коммутатор, используя конфигурационные файлы server.xml, channel.xml и mux.xml.
- Мы можем направить сообщение на основе IP-конфигурации, которая указана в channel.xml, которая является статической (в смысле это предопределено).
Требование: я хочу разработать приложение с использованием JPOS Q2 Server в качестве маршрутизатора платежного шлюза. Основным требованием является то, что сервер Q2 должен иметь возможность маршрутизировать входящее сообщение на основе одного поля (в качестве идентификатора) из этого входящего сообщения, динамически выбирать маршрут назначения из базы данных и отправлять сообщение дальше на хост назначения. Это можно сделать с помощью сервера JPOS Q2? Если да, то как?
Поток сообщений: Источник -> (сообщение ISO с полем 48 в качестве идентификатора)-> СЕРВЕР Q2 -> (Выполнить некоторую обработку, получить адрес получателя, используя идентификатор из БД)-> Хост назначения -> (Обратный ответ источнику в обратном порядке)
1 ответ
Боюсь, что jPOS не поддерживает это из коробки, но у вас есть несколько способов добиться этого.
Вы можете определить ChannelAdaptor для каждого возможного адреса, если их слишком много, вы можете создать своего рода сценарий, который генерирует файлы развертывания из базы данных. Я предполагаю, что у каждого назначения будет описательное имя в этой базе данных, так что вы можете использовать его для присвоения имени адаптеру канала.
Затем вы можете у участника, который получает пункт назначения, также получить это имя. Затем вы помещаете в контекст это место назначения и используете свою собственную логику или участника QueryHost, как описано в разделе 9.8.4 руководства по программированию jpos.
Если у вас нет имени в БД, то вы можете использовать собственное именование и определить отображение в некоторых свойствах или XML-файле. Также вы можете использовать адрес назначения в качестве самого названия канала (предпочтительно с префиксом), если у вас нет лучшего способа.
Другой подход (я не знаю, лучше или хуже, но склонен к худшему) может состоять в том, чтобы динамически создать канал для отправки сообщения пользовательскому участнику и вообще не использовать ChannelAdaptor. Это потребует больше Java-логики и меньше конфигурации, а также вы потеряете преимущества использования стандартных компонентов.
Это всего лишь два варианта, о которых я сразу подумал, но, может быть, другие, которые мне не хватает Я настоятельно рекомендую пойти по первому пути с возможным сценарием, который обновляет файлы дескриптора адаптера канала, если таблица назначения слишком переменная или слишком большая (второе, я сомневаюсь, но на всякий случай, о котором я упоминал).
По сути, вы пишете что-то вроде большого шлюза, поэтому, если вы еще не читали учебники по шлюзу jpos ( сначала обо всем), пожалуйста, прочитайте их, и вы поймете, как склеить то, что вы нашли в разделах 9.8. *. Вы будете основывать свой код в SelectDestination участник.