|
Oracle® Application Server Integration InterConnect Adapter for Oracle Applications Installation and User's Guide
10g Release 2 (10.1.2) B14360-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Integration InterConnect Adapter for Oracle Applications Installation and User's Guide
10g Release 2 (10.1.2) B14360-02 |
|
|
Previous |
Next |
This chapter provides answers to frequently asked questions about the OA adapter. It contains frequently asked questions for following categories:
This sections explains following frequently asked questions about the OA adapter:
What should I enter on the Database User Configuration dialog box during installation?
Is it possible to edit the database configuration settings created during installation?
This information is used to find where the stored procedures generated through iStudio will be installed for application inbound messages. At run time, the OA adapter uses this information to call a user-specified stored procedure. This user is typically the APPS user of the Oracle Applications.
Edit the adapter.ini file located in the ORACLE_HOME/integration/interconnect/adapters/[AppType][Partition] directory.
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
Following design time related frequently asked questions are explained:
What is the Returned IN Args feature in iStudio and how do I use it?
How do I export stored procedures to use with the OA adapter?
The PL/SQL code is saved in the ORACLE_HOME/integration/interconnect/iStudio directory. iStudio allows any extension to be specified, which is used to prefix the name of every SQL file, generated through iStudio. The following convention is used in naming the SQL files:
PrefixSpecifiedInIStudio_ApplicationName_BusinessObjectTYPES.sql PrefixSpecifiedInIStudio_ApplicationName_BusinessObject.sql
Please refer to "Returned In Arguments" in Oracle Application Server Integration InterConnect User's Guide.
The following steps describe how to export procedures for the OA adapter.
Use iStudio and select Export from the File menu. The Export Stored Procedures dialog is displayed.
Select the root of the list to select all stored procedures from all applications.
Two files are created for each application and business object, if a base name is selected. The base name_application name_business object name.sql file defines all stored procedures for all messages from the selected business object and application. The base name_applicationname_business object nameTYPES.sql file defines all types used by the stored procedures in the first file.
If you do not want to export all stored procedures, for all applications, as this can take a while, then select one or more applications. Only the stored procedures for those applications will be generated. You can also select messages based on the role. For example, if you select publish, then only publish messages will be generated. Or, you can select to export the stored procedures for specific messages by selecting those messages in the list.
The database does not allow arrays of arrays. Therefore, the application view of OA messages should not contain arrays of arrays. For example, the application view of an OA message can contain an array of Customers, where each message contains one Address. However, it cannot contain an array of Customers, where each contains an array of Addresses.
Following run time related frequently asked questions are explained:
Why is the OA adapter using old information after I changed information in iStudio?
Why do I get errors when trying to load PL/SQL code generated through iStudio?
What are the steps to prepare a OA adapter that publishes events?
What are the steps to prepare a OA adapter that invokes procedures?
What are the steps to prepare a OA adapter that subscribes to events?
What are the steps to prepare a OA adapter that implements procedures?
A start executable that is not the OracleAS Integration InterConnect start script must be running. This is dependent on what is in the PATH environment variable. Therefore, run the start script as follows:
| Platform | Executable |
|---|---|
| UNIX | ./start
|
| Windows | Use the Service Panel. |
The OA adapter caches the information from iStudio (the information which is stored in the Repository) locally for better performance in a production environment. If you change something in iStudio and want to view it in the run-time environment, then stop the OA 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.
Use the search facility if you are unable to find your object under the module name.
Ensure you none of the PL/SQL reserved keywords are used in OracleAS Integration InterConnect messages. For example, for a Phone object contains the attributes areacode and number, a problem would occur because number is a reserved keyword in PL/SQL.
Before an OA adapter can publish events, some stored procedures need to be generated in iStudio.
iStudio will create two SQL scripts for a publish message, one with stored procedures and one with types. The types script name will end with TYPES.sql. Using any user name, load the types scripts and the stored procedure script into the database.
When an event occurs, there are several PL/SQL methods that must be called to publish the event message. All of the methods reside in the event business object package which is created in the stored procedure SQL script. The first procedure that must be called is crMsg_event name_event owner_event version. It has two out arguments which are both of type number: the message id and the root data type id.
Next, populate the message with the correct data. For each nonprimitive attribute that the message contains, there is a function called cr_data type name_attribute name. This function has one argument for each primitive attribute it contains and it takes the message id and the parent data type id. It returns a number, which is the data type id. When all data types have been created, a procedure must be called to publish the message. This procedure is named pub_event name_eventowner_event version. This procedure has three arguments: the message id, the source application name, and the destination application name. The destination application name is ignored, so pass in whatever is applicable.
For example, an event in the Customer business object is called create. Application A publishes this event. The application view of this event contains an attribute called C of type cust. The cust type contains a name attribute, which is a String and a loc attribute of type Location. The Location type contains a city attribute, which is a String, and a state attribute, which is also a String. The following code will publish a create event.
DECLARE
moid NUMBER;
aoid NUMBER;
custid NUMBER;
locid NUMBER;
BEGIN
Customer.crMsg_create_TEST_V1(moid, aoid);
custid := Customer.cr_cust_c('Homer', moid, aoid);
locid := Customer.cr_Location_loc('Redwood Shores', 'CA', moid, custid);
Customer.pub_create_TEST_V1(moid, 'a', '');
END
This is very similar to publishing events. All of the steps are the same until the final procedure call. The name is inv_proc name_proc_owner_proc version and has three IN arguments: the message id, the source application name, and a timeout. The timeout is how many seconds to wait for a response. The event also has as many OUT arguments as the procedure defined in iStudio has.
Before an OA adapter can subscribe to events, some stored procedures need to be generated in iStudio.
iStudio will create two SQL scripts for a subscribe message: one with stored procedures and one with types. The types script name will end with TYPES.sql. Under the same user name specified on the Database Configuration page during installation, load the types scripts and the stored procedure script into the database. A pre-existing user can be specified, but if a user name that does not exist is entered, that user must be created manually.
The OA adapter will call the procedure sub_event name_event owner_event version in the package eventbusiness object when a message is received. Add PL/SQL code in this method to perform whatever tasks are necessary when this kind of message is received. This code can be added in iStudio when creating the message, or modify the stored procedure SQL script before loading it into the database.
The steps are very similar to subscribing to events. However, the procedure that the OA adapter will call is imp_procname_proc owner_proc version. This procedure will have OUT arguments corresponding to the OUT arguments in the procedure defined in iStudio. In addition to writing PL/SQL code to perform the necessary tasks, the OUT arguments must be filled in with correct values. Write this code in iStudio when creating the message, or modify the stored procedure SQL script before loading it into the database. If the start script is used to start the OA adapter, then there is a way to determine whether the OA adapter was started properly. This can be viewed in the log.xml file in the logs directory of the OA adapter.
If all the queues the OA adapter connects to on the application database 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 OA adapter uses a consumer name to indicate to OracleAS Integration InterConnect to pick up this message. The following two options help you to find out the consumer name to use:
If the piece of code that writes the message to the OA adapter is already written, 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 OA adapter is not written, then type in any string as the consumer name. When that piece of code is built, ensure that the consumer names match.
ANY tags in an XML DTD allow unstructured data in XML to be used. 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 OracleAS Integration InterConnect to know about the structure:
The simplest method is to modify the DTD being importing into iStudio and replace the ANY tag with structured data. When modifying the DTD, only a copy of the DTD being importing into iStudio is modified, not the published version of the DTD. For example, if the USERAREA ANY 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 a 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 run time. If the XML will use the ANY tag in different ways at run time, a union can be used. For example, if address has street, city, and state only for some instances and for other instances only has zip, a standard DTD union mechanism for doing this can be used.
The following steps describe a second approach which involves creating a separate DTD which defines the structure used at run time for the ANY tag.
Import the DTD for the event, either while creating an ADT or while creating the published or subscribed event or the invoked or 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 a PCDATA tag for the ANY element. The ANY element must have a subelement 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)>
Then import the address_any.dtd by right-clicking on the address ADT in iStudio. This assumes 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>
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 myMQApp. Later, you changed the application name in iStudio to MQApp. In such case, you need to specify the password corresponding to the new application name MQApp in the Oracle Wallet. You can create password by using the oraclewallet command.
