Можем ли мы подождать, пока движок приложения PeopleSoft дождется завершения асинхронных сообщений?

Я пытаюсь обработать загрузку данных, когда я пытаюсь асинхронно публиковать сообщения через PeopleSoft через Integration Broker в Application Engine. Весь смысл в том, чтобы иметь возможность отправлять несколько сообщений и потреблять их в одном узле. Прежде чем отправлять сообщения, я сохраняю данные в таблице (скажем, T1), чтобы сохранить все значения полей в файле загрузки.

При потреблении я пытаюсь представить каждое сообщение интерфейсу компонентов, и исключения регистрируются в той же таблице T1. Допустим, для каждой транзакции мы помечаем поле таблицы (скажем, Processed_flag = 'Y').

Мне нужен механизм, в котором я мог бы просто ждать завершения всех асинхронных сообщений. Я думаю проверить таблицу T1, если в таблице T1 есть какие-либо строки, где Processed_flag равен «N», просто заставьте поток спать на большее время. Пока все сообщения не обработаны, держите его в спящем режиме и не позволяйте движку приложения завершить работу.

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

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

Любые комментарии по этому подходу будут оценены. Заранее спасибо!


person startedFromTheBottom    schedule 25.02.2014    source источник


Ответы (1)


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

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

  1. Мы будем обновлять таблицу T1 для всех обработанных/успешных/неудачных строк, поскольку мы продолжаем получать сообщения и использовать их по мере необходимости.

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

Я надеюсь, что это может помочь любому, кто имеет дело с этими проблемами загрузки. Спасибо!

person startedFromTheBottom    schedule 27.02.2014