Oracle® Application Server Integration InterConnect Adapter for AQ Installation and User's Guide
10g Release 2 (10.1.2) B14077-02 |
|
Previous |
Next |
This chapter provides answers to frequently asked questions about the AQ adapter:
Why is the AQ adapter using old information after I changed information in iStudio?
How can I deliver a message to a specific partition of the publishing adapter?
View the log.xml
file located in the time-stamped subdirectory of the AQ adapter log
directory:
Platform | Directory |
---|---|
UNIX | ORACLE_HOME /integration/interconnect/adapters/ Application /log/ timestamp_in_milliseconds
|
Windows | ORACLE_HOME \integration\interconnect\adapters\ Application \log\ timestamp_in_milliseconds
|
where Application
is the value you defined in Step 6, and timestamp_in_milliseconds
is the directory. If no exceptions are listed, then the adapter has started properly.
View the exceptions in the AQ adapter log file (log.xml
). The exceptions should provide some idea about what went wrong. It is possible that the AQ adapter is unable to connect to the repository. Ensure that the repository is started properly. Once the repository is started properly, the AQ adapter will connect to it. You do not need to restart the adapter.
See Also: Oracle Application Server Integration InterConnect User's Guide for instructions on starting the repository on UNIX and Windows |
One reason can be that Oracle Wallet does not contain the password information corresponding to your application name. For example, during installation you defined the application name as myAQApp
. Later, you changed the application name in iStudio to AQApp
. In such case, you need to specify the password corresponding to the new application name AQApp
in the Oracle Wallet. You can create password by using the oraclewallet
command.
The AQ adapter caches the information from iStudio that is stored locally in the repository for better performance in a production environment.
If you change something in iStudio and want to view it in the runtime environment, then stop the AQ adapter, delete the cache files, and restart the adapter.
Each adapter has a persistence directory located in the adapter's directory. Deleting this directory when adapter has been stopped allows the adapter to obtain the new metadata from the repository when started.
The database referred during installation are those on the application side from which the adapter will either put or get messages from Advanced Queuing.
If all the queues that the AQ adapter connects to on the application side are single consumer queues, then leave this blank. However, if any one of the queues is a multiconsumer queue, then specify a consumer name.
The application that writes to the AQ adapter uses a consumer name to indicate to OracleAS Integration InterConnect to pick up this message. Use one of the following methods to determine the consumer name to use:
If the piece of code that writes the message to the AQ adapter is already available, then look at that code or the documentation that comes with it to find the consumer name.
If the piece of code that writes the message to the AQ adapter is not available, then enter any string as the consumer name. When that piece of code is built, ensure that the consumer names match.
B2B listens on the IP_OUT_QUEUE
as b2bUser
, whereas InterConnect does not enqueue the message for any specific user. As a result, B2B does not pick up the messages.
Use the 'AddHeader' transformation in the subscribing adapter transformation mapping. The field should be 'aq_recipients' and the value should consist of comma-delimited consumer names.
Edit the parameters in the following file:
Platform | Directory |
---|---|
UNIX | ORACLE_HOME /integration/interconnect/adapters/ Application /adapter.ini
|
Windows | ORACLE_HOME \integration\interconnect\adapters\ Application \adapter.ini
|
The following table lists the parameters and their corresponding questions in the installation:
Parameter | Parameter Information |
---|---|
aq_bridge_consumer_name
|
The consumer name |
aq_bridge_host
|
Host |
aq_bridge_instance
|
The database SID |
aq_bridge_owner
|
The Advanced Queuing owner. Enter the value if your Advanced Queuing adapter is installed under a different user than aq_bridge_username .
|
aq_bridge_port
|
The TNS listener port |
aq_bridge_thinjdbc
|
Use a THIN JDBC driver if true, otherwise use OCI8 JDBC driver. |
a q_bridge_username
|
User name |
Specify the partition name before publishing a message to the queue specified in iStudio, for the publish event corresponding to this message. You can do this by using a trigger or Java AQ API. When using Java AQ API , specify the partition name for the AQ Agent. When using a trigger, specify the specify the application name followed by the partition name as value of variable recip_agent
. For example, application AQAPP
has two partitions PAR1
and PAR2
. An AQ adapter is publishing an event Create_Customer
to the hub queue. To enable the PAR2
partition to receive message from the AQ and publish it to the hub, create the following trigger for a database table and specify the application name followed by the partition name as value of variable recip_agent
:
CREATE OR REPLACE TRIGGER AQAPP.ENQUEUE_NEW_CUST BEFORE INSERT ON AQAPP.CUSTOMER_TABLE FOR EACH ROW DECLARE qname VARCHAR2(20); enqueue_options DBMS_AQ.ENQUEUE_OPTIONS_T; message_properties DBMS_AQ.MESSAGE_PROPERTIES_T; msgid RAW(16); recip_agent SYS.AQ$_AGENT; raw_payload RAW(32767); payload VARCHAR2(256); recipient_list DBMS_AQ.AQ$_RECIPIENT_LIST_T; BEGIN qname := 'OUTBOUND_QUEUE'; payload := '<?xml version="1.0" standalone="no"?>' || '<Customer>'|| '<id>' || :new.Id || '</id>' || '<action>' || :new.Action || '</action>' || '<name>' || :new.Name || '</name>' || '<addr>'|| '<street>' || :new.Street || '</street>' || '<city>' || :new.City || '</city>' || '<state>' || :new.State || '</state>' || '<zip>' || :new.Zip || '</zip>' || '</addr>' || '</Customer>'; recip_agent := SYS.AQ$_AGENT('AQAPPPAR2',NULL,NULL); --AQAPP is application name and PAR2 is partition name recipient_list(1) := recip_agent; message_properties.recipient_list := recipient_list; raw_payload := UTL_RAW.CAST_TO_RAW( payload ); DBMS_AQ.ENQUEUE( queue_name => qname , enqueue_options => enqueue_options,message_properties => message_properties, payload => raw_payload, msgid => msgid ); END;
ANY
tags in an XML DTD allow unstructured data to be used in XML. OracleAS Integration InterConnect, however, must know about the structure of that data (using a DTD) if that data is to be used in mappings.
There are two methods for to know about the structure of the data:
The simplest method is to modify the DTD being imported into iStudio and replace the ANY
tag with structured data. When modifying the DTD, only a copy of the DTD being imported into iStudio is modified, not the published version of the DTD. For example, if the USERAREA AN
Y
tag is edited before importing the DTD into iStudio, only a copy is changed and the published OAG definition, which other people who download the OAG DTDs would use, is not changed.
This approach also supports using PCDATA for an ANY
tag.
For example, consider the following customer.dtd
:
<!ELEMENT customer (name, phone, address)> <!ELEMENT name (#PCDATA)> <!ELEMENT phone (#PCDATA)> <!ELEMENT address ANY)>
This customer.dtd
can be changed to the following:
<!ELEMENT customer (name, phone, address)> <!ELEMENT name (#PCDATA)> <!ELEMENT phone (#PCDATA)> <!ELEMENT customer (name, phone, address)> <!ELEMENT name (#PCDATA)> <!ELEMENT phone (#PCDATA)> <!ELEMENT address (#PCDATA)> <!ELEMENT street (#PCDATA)> <!ELEMENT city (#PCDATA)> <!ELEMENT zip (#PCDATA)>
This is dependent on what the XML will conform to at runtime. If the XML will use the ANY
tag in different ways at runtime, a union can be used. For example, if address
has street
, city
, and state
only for some instances and for other instances has zip
only, then a standard DTD union mechanism can be used to do this.
The following steps describe a second approach that involves creating a separate DTD and defines the structure used at runtime for the ANY
tag.
Import the DTD for the event, while creating an Application Data Type or creating the published/subscribed event or the invoked/implemented procedure. iStudio warns about the ANY
tag and points out the type that needs to be modified.
Reload the iStudio project.
Under the list of ADTs, find the type corresponding to the ANY
element and right-click to display the context menu. This is the ADT mentioned in Step a.
Import a DTD, which defines the structure planned to use, for the ANY
tag.
This method does not support using PCDATA
tag for the ANY
element. The ANY
element must have a sub-element in this case.
For example, consider the following, customer.dtd
:
<!ELEMENT customer (name, phone, address)> <!ELEMENT name (#PCDATA)> <!ELEMENT phone (#PCDATA)> <!ELEMENT address ANY)>
When this DTD is imported, iStudio warns that the address
tag is an ANY
tag and it corresponds to the address
ADT in iStudio.
The address_any.dtd
could look like the following:
<!ELEMENT address_any (street, city, zip)> <!ELEMENT street (#PCDATA)> <!ELEMENT city (#PCDATA)> <!ELEMENT zip ANY)>
Import the address_any.dtd
by right-clicking the address ADT in iStudio. This assumes that the XML has an address_any
element under the address element, as follows:
<address> <address_any> <street> <city> <zip> </address_any> </address>
If the address_any
element is not needed, then instead of editing the address ADT, edit customer ADT and change the type of address attribute from address
to address_any
, after importing address_any
elsewhere. The following is now true:
<address> <street> <city> <zip> </address>
OracleAS Integration InterConnect uses Oracle Wallet Manager to maintain system passwords. When you install OracleAS Integration InterConnect, Oracle Wallet Manager is also installed and a password store is created. All passwords used by OracleAS Integration InterConnect components are stored in the password store. The password is stored in the Oracle Wallet in the following format:
ApplicationName/password
The ApplicationName
is the name of the application, which is extracted from the adapter.ini
file of the corresponding adapter. In the adapter.ini
file, the application
parameter specifies the ApplicationName
to which this adapter connects. The password for the application is also retrieved from the adapter.ini
file.
The number of entries is dependent on the type of adapter. For example, DB Adapter needs two entries whereas AQ Adapter needs only one entry. The following table lists the entries that will be created for each adapter:
Adapter | Entry In Oracle Wallet |
---|---|
AQ | ApplicationName /aq_bridge_password
|
HTTP | ApplicationName /http.sender.password
|
HTTP | ApplicationName /sender.wallet_password
|
SMTP | ApplicationName /smtp.receiver.password
|
MQ | ApplicationName /mq.default.password
|
FTP | ApplicationName /file.sender.password
|
FTP | ApplicationName /file.receiver.password
|
DB | ApplicationName /db_bridge_schema1_password
|
DB | ApplicationName /db_bridge_schema1_writer_password
|
You can create, update, and delete passwords using the oraclewallet
command. When you run the command, it prompts you for the admin password.
You can use the following commands to manage your passwords:
List all passwords in the store
oraclewallet -listsecrets
Create a password
oraclewallet -createsecret passwordname
For example, to create a password for the hub schema:
oraclewallet -createsecret hub_password
View a password
oraclewallet -viewsecret passwordname
For example, to view the password for the hub schema:
oraclewallet -viewsecret hub_password
Update a password
oraclewallet -updatesecret passwordname
For example, to update the password for the hub schema:
oraclewallet -updatesecret hub_password
Delete a password
oraclewallet -deletesecret passwordname
For example, to delete the password for the hub schema:
oraclewallet -deletesecret hub_password