Oracle — это не одна точка интеграции

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

СУБД отвечает за хранение и транзакционность.

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

AMPE разделяет эти уровни.

Для аналитики может быть оправдан controlled read access или отдельная реплика.

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

Oracle Fusion Cloud Applications предоставляет REST API для работы с прикладными данными.

Это важная архитектурная граница.

Внешняя система должна понимать бизнес-ресурс и контракт, а не внутреннюю физическую схему хранения SaaS-продукта.

Так интеграция лучше переживает развитие самой платформы.

Oracle GoldenGate работает с потоком изменений и может быть сильным инструментом для CDC, репликации и near-real-time передачи данных между системами.

Но это другой класс задачи, чем API-интеграция.

API передаёт бизнес-операцию или ресурс.

CDC передаёт факт изменения данных.

Если downstream должен понимать «заказ подтверждён» как бизнес-событие, не всегда правильно заставлять его восстанавливать этот смысл из набора изменений таблиц.

Поэтому AMPE отделяет data integration от business integration.

Когда нужно без тяжёлых full load передавать большие объёмы изменений.

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

Когда выполняется миграция с минимальным downtime.

Когда новая система некоторое время должна жить параллельно со старой.

Когда прямое чтение production создаёт нежелательную нагрузку.

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

Изменилась строка.

Что это означает для бизнеса?

Если этот смысл важен downstream-системе, его нужно определить явно.

Иначе технически точная реплика данных может давать управленчески неверную картину.

• Создан документ?

• Изменён статус?

• Исправлена техническая ошибка?

• Произошла часть длинной транзакции?

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

Они отличаются интерфейсами, моделью security, требованиями к network access и темпом изменений.

AMPE не пытается насильно привести весь ландшафт к одной технологии.

Мы создаём устойчивую границу между разными поколениями систем.

Смысл — не в унификации протокола, а в унификации ответственности и наблюдаемости.

• Иногда это REST.

• Иногда integration platform.

• Иногда messaging.

• Иногда CDC.

• Иногда контролируемый batch.

Клиент существует в нескольких приложениях.

Попытка сделать все системы одинаково authoritative создаёт конфликт.

AMPE фиксирует system of record для конкретного атрибута или объекта и строит движение данных вокруг этой ответственности.

• Финансовое состояние — в одном.

• Коммерческий контекст — в другом.

• Master data — в третьем.

• Аналитическая история — в четвёртом.

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

AMPE проектирует переходное состояние так же внимательно, как целевое.

• Старая система ещё принимает операции.

• Новая уже должна получать изменения.

• Исторические данные загружаются отдельно.

• В какой-то момент ownership переключается.

• Здесь особенно важны

  initial load; incremental synchronization; reconciliation; cutover; rollback plan.

Прикладная логика не обходится случайным SQL там, где это опасно.

REST/API используются как бизнес-границы там, где их предоставляет продукт.

CDC применяется для задач, где нужен именно поток изменений.

Аналитическая нагрузка не мешает транзакционной системе.

Старые и новые компоненты соединены через понятные контракты.

Ошибки обмена можно увидеть и восстановить.

Ownership данных определён до начала синхронизации.