Oracle GoldenGate Java User Exit

3.2 Oracle GoldenGate Java User Exit

https://docs.oracle.com/goldengate/gg12121/gg-adapter/GADAD/intro_java.htm#GADAD111

Through the Oracle GoldenGate Java API, transactional data captured by Oracle GoldenGate can be delivered to targets other than a relational database, such as a JMS (Java Message Service), files written to disk, or an integration with a custom application Java API.

Oracle GoldenGate for Java provides the ability to execute Java code from the Oracle GoldenGate Extract process. Using Oracle GoldenGate for Java requires two components:

• A dynamically linked or shared library, implemented in C/C++, integrating as a User Exit (UE) with the Oracle GoldenGate Extract process through a C API.
• A set of Java libraries (jars), which comprise the Oracle GoldenGate Java API. This Java framework communicates with the user exit through the Java Native Interface (JNI).

Figure 3-2 Configuration for Delivering JMS Messages

Description of "Figure 3-2 Configuration for Delivering JMS Messages"
This graphic shows a typical configuration delivering data as JMS messages. The source Oracle GoldenGate instance sends transactional data to the target as a trail. The trail is processed by an Extract linked to a Java user exit and JMS handler that create the JMS messages.

3.2.1 Delivery Configuration Options

The dynamically linked library is configurable using a simple properties file. The Java framework is loaded by the user exit and is also initialized by a properties file. Application behavior can be customized by:

• Editing the property files; for example to:
  • Set host names, port numbers, output file names, JMS connection settings;
  • Add/remove targets (such as JMS or files) by listing any number of active handlers to which the transactions should be sent;
  • Turn on/off debug-level logging, etc.
  • Identify which message format should be used.
• Customizing the format of messages sent to JMS or files. Message formats can be custom tailored by:
  • Setting properties for the pre-existing format process (for fixed-length or field-delimited message formats);
  • Customizing message templates, using the Velocity template macro language;
  • (Optional) Writing custom Java code.
• (Optional) Writing custom Java code to provide custom handling of transactions and operations, do filtering, or implementing custom message formats.

There are existing implementations (handlers) for sending messages via JMS and for writing out files to disk. There are several predefined message formats for sending the messages (e.g. XML or field-delimited); or custom formats can be implemented using templates. Each handler has documentation that describes its configuration properties; for example, a file name can be specified for a file writer, and a JMS queue name can be specified for the JMS handler. Some properties apply to more than one handler; for example, the same message format can be used for JMS and files.