|
Oracle® BPEL Process Manager Developer's Guide
10g Release 2 (10.1.2) Part No. B14448-01 |
|
 Previous |
 Next |
|
Oracle® BPEL Process Manager Developer's Guide
10g Release 2 (10.1.2) Part No. B14448-01 |
|
|
Previous |
Next |
This appendix contains the following topics:
The following sections describe possible issues and solutions.
Problem
At run time, you may see the exception "Could not create the TopLink session."
Solution
This common error occurs when the run-time connection is not configured properly. See "Deployment" for more information.
Problem
You may see the exception "Could not find adapter for eis/DB/my_connection/...."
Solution
See "Deployment" for more information.
Changes through TopLink Mapping Workbench require you to run the Adapter Configuration Wizard again in edit mode to force a refresh of the toplink_mappings.xml file.
Problem
Changes to Customers_table.xsd are not reflected, or you get an exception.
Solution
You cannot specify the XSD format that the database adapter produces. See "XML Schema Definition (XSD)" for details.
Problem
After clicking Finish, or at deployment, you may see the following exception:
Caused by Exception [TOPLINK-0] (OracleAS TopLink - 10g (9.0.4.4) (Build 040705)): oracle.toplink.exceptions.IntegrityException Descriptor Exceptions: ---------------------- Exception [TOPLINK-64] (OracleAS TopLink - 10g (9.0.4.4) (Build 040705)): oracle.toplink.exceptions.DescriptorException Exception Description: No target foreign keys have been specified for this mapping. Mapping: oracle.toplink.mappings.OneToManyMapping[phonesCollection] Descriptor: Descriptor(Test.Customers --> [DatabaseTable(CUSTOMERS)])
This generally means that there was a problem in the wizard.
Solution
The simplest solution is to create all constraints on the database first. Also, depending on the problem, you may only need to fix something in the offline tables, and then run the wizard again.
If you want to create a one-to-many mapping from CUSTOMERS to PHONES, you need a foreign key constraint on PHONES.
This procedure assumes that this constraint does not exist on the database, and that you tried to create it with the wizard and it generated an exception.
In your JDeveloper BPEL Designer project, click the plus sign (+) in Application Navigator to add files to your project. Select database > schemaName > schemaName.schema. This imports all your database objects.
Open the PHONES table and manually create the foreign key constraint from PHONES to CUSTOMERS.
Save all.
Now open the OracleAS TopLink project. In JDeveloper BPEL Designer, go to ApplicationSources > TopLink > TopLinkMappings. In the Structure window, open CUSTOMERS and double-click the phonesCollection mapping.
You should now see a Table Reference tab in the main window. This was probably blank previously. From the menu, select the one you just created.
Save again.
Edit the database partner link.
Click Next to the end, and then click Finish and Close.
This refreshes toplink_mappings.xml for your project.
Open the toplink_mappings.xml file in JDeveloper BPEL Designer. You may need to add it to the project first.
Search for phonesCollection.
You should find a tag like this:
<database-mapping> <attribute-name>phonesCollection</attribute-name>
Scroll down and you should now see something like this:
<source-key-fields> <field>CUSTOMERS.someColumn</field> </source-key-fields> <target-foreign-key-fields> <field>PHONES.someColumn</field> </target-foreign-key-fields>
If you do not see the tags shown here, then manually add them. This is not the preferred method because toplink_mappings.xml is a generated file, which gets refreshed whenever you edit a database partner link.
Undeploy the old process in Oracle BPEL Console, and redeploy your fixed process with a new revision number.
Problem
After clicking Finish, or at deployment, you may see the following exception:
Caused by Exception [TOPLINK-0] (OracleAS TopLink - 10g (9.0.4.4) (Build 040705)): oracle.toplink.exceptions.IntegrityException Descriptor Exceptions: ---------------------- Exception [TOPLINK-46] (OracleAS TopLink - 10g (9.0.4.4) (Build 040705)): oracle.toplink.exceptions.DescriptorException Exception Description: There should be one non-read-only mapping defined for the primary key field [PHONES.ID]. Descriptor: Descriptor(Test.Phones --> [DatabaseTable(PHONES)])
This probably means that no primary key was defined for PHONES.
Solution
If this exception appears in conjunction with the No Target Foreign Keys error, then see "No Target Foreign Keys Error" and resolve that problem first. Otherwise, do the following:
Open ApplicationSources > TopLink > TopLinkMappings.
In the Structure window, double-click PHONES.
On the first page, you should see Primary Keys:. Ensure that columns are selected and that they are mapped in the project.
Save.
Edit the database partner link.
Click Next to the end of the wizard, and then click Finish and Close.
Open toplink_mappings.xml. For the PHONES descriptor, you should see something like this:
<primary-key-fields> <field>PHONES.ID</field> </primary-key-fields>
Make sure that there is at least one field, and for that field, make sure you can find it somewhere else in the toplink_mappings.xml file. If you can, then this means that the database adapter will detect it. If not, then you must map this field.
Open Application Sources > Test > Phones.
You should see Java code. Add a line as follows:
long id;
Save.
Now open ApplicationSources > TopLink > TopLinkMappings.
Double-click PHONES and go to the Structure window.
You should be able to map the id as DirectToField, and set the database field to ID.
Save and then edit the database partner link.
Click Next to the end, and then click Finish and Close.
Undeploy the old process in Oracle BPEL Console, and redeploy your fixed process with a new revision number.
Problem
You may get a conversion exception when you pass in an xs:dateTime value to the database adapter.
Solution
If an attribute is of type xs:dateTime, then the database adapter is expecting a string in one of the following formats:
1999-12-25T07:05:23-8:00 1999-12-25T07:05:23.000-8:00 1999-12-25T15:05:23:000Z 1999-12-25T15:05:23
The format 1999-12-25 is accepted, although it is not a valid xs:dateTime value. The xs:dateTime format is yyyy-MM-ddTHH:mm:ss.SSSZ, where
yyyy is the year (2005, for example)
MM is the month (01 through 12)
dd is the day (01 through 31)
HH is the hour (00 through 23)
mm is the minute (00 through 59)
ss is the second (00 through 59)
SSS is milliseconds (000 through 999), optional
Z is the time zone designator (+hh:mm or -hh:mm), optional
A DATE column may exist on an Oracle Database, which can accept 25-DEC-1999 date format. However, this is not a date format that the database adapter can accept. The following workaround applies to TopLink only.
If you want to pass in the 25-DEC-1999 date format, then map the attribute as a plain string. The database adapter will pass the value through as-is.
To do this you must edit the offline database table and change the column datatype from DATE to VARCHAR2.
Save.
Edit the database partner link.
Click Next to the end, and then click Finish and Close.
While not a valid xs:dateTime format, the format yyyy-mm-dd is a valid xs:date format.
Problem
The time portion of DATE fields may be truncated on Oracle9 or greater platforms when using oracle.toplink.internal.databaseaccess.DatabasePlatform. For example, 2005-04-28 16:21:56 becomes 2005-04-28T00:00:00.000+08:00.
Or, the millisecond portion of DATE fields may be truncated on Oracle9 or greater platforms when using oracle.toplink.internal.databaseaccess.Oracle9Platform. For example, 2005-04-28 16:21:56.789 becomes 2005-04-28T16:21:56.000+08:00.
Or, you may have trouble with TIMESTAMPTZ (timestamp with time zone) or TIMESTAMPLTZ (time stamp with local time zone).
Solution
You must set the platformClassName for Oracle platforms, because these include special workarounds for working with date-time values on Oracle. So, if you are connecting to an Oracle9 platform, you must set the platformClassName accordingly.
Due to an issue with the time portion of DATE being truncated with Oracle9 JDBC drivers, the property "oracle.jdbc.V8Compatible" was set when using any Oracle platform class name. So use oracle.toplink.internal.databaseaccess.Oracle9Platform to solve the time truncation problem.
However, starting with Oracle 9, dates started to include millisecond precision. Setting oracle.jdbc.V8Compatible in response had the drawback of returning the milliseconds as 000, as an Oracle 8 database would have done. (This also introduced an issue with null IN/OUT DATE parameters for stored procedure support). You do not see any truncation (of the time portion or milliseconds) when using the Oracle9Platform class.
You must also use the Oracle9Platform class if you have TIMESTAMPTZ and TIMESTAMPLTZ.
If you want DATE to be treated like a date (with no time portion), set the attribute-classification in the toplink_mappings.xml to java.sql.Date.
In general if you are having an issue with a particular database, you should check to see if TopLink has a custom platformClassName value for that database, and whether you are using it.
See "Deployment" for more information. Also, see Table 20-19, "Application Server Connection Pooling" for more information.
To understand how to handle faults, such as a unique constraint violation on inserts or when a database or network is temporarily unavailable, see the InsertWithCatch tutorial at Oracle_home\integration\orabpel\samples\tutorials.
Problem
A BPEL process modeled against one database will not run against another database.
The most likely cause for this problem is that you are using a different schema in the second database. For example, if you run the wizard and import the table SCOTT.EMPLOYEE, then, in the toplink_mappings.xml file, you will see SCOTT.EMPLOYEE. If you run the sample in the USER schema on another database, you will get a "table not found" exception.
Solution
Until qualifying all table names with the schema name is made optional, manually edit toplink_mappings.xml and replace SCOTT. with nothing, as shown in the bold portions of the following example.
Change
<project>
<project-name>toplink_mappings</project-name>
<descriptors>
<descriptor>
<java-class>BPELProcess1.A</java-class>
<tables>
<table>SCOTT.A</table>
</tables>
To
<project>
<project-name>toplink_mappings</project-name>
<descriptors>
<descriptor>
<java-class>BPELProcess1.A</java-class>
<tables>
<table>A</table>
</tables>
You must repeat this step every time after running the Adapter Configuration Wizard.
|
Note: HavingEMPLOYEE on both the SCOTT and USER schemas, and querying against the wrong table, can result in a problem that is difficult to detect. For this reason, the database adapter qualifies the table name with the schema name.
|
Problem
Many departments with many employees are read in, but only one employee per department appears.
Solution
You must use a transform with a for-each. An Assign activity with a too-simplistic XPath query can result in only the first employee being copied over.
Problem
If you have an outbound SELECT to find all employees where firstName = some_parameter, then you will have a problem if firstName on the database is a CHAR column, as opposed to a VARCHAR2 column.
It is a known problem with some databases that if you insert a CHAR value (for example, 'Jane') into a CHAR(8) field, then the database pads the value with extra spaces (for example, 'Jane ').
If you then execute the query
SELECT ... WHERE firstName = 'Jane';
no rows may be returned. Although you are querying for the same value that you inserted, and some tools such as SQL*PLUS and SQLWorksheet operate as expected, the query does not work with the database adapter.
Solution
The best practice is to use a CHAR column for fields that must be fixed, such as SSN, and VARCHAR2 for columns that can take a variable length, such as firstName.
Transforming the value to add padding may be difficult, and using SELECT to trim the value on the database (as opposed to padding the other side) requires using SQL statements. For example:
SELECT ... WHERE trim(firstName) = #firstName;
Note that # is an OracleAS TopLink convention for denoting input parameters.
Problem
When querying on table A, which has a one-to-one relationship to B, where B contains a CLOB, you may see the following exception:
Exception Description: java.sql.SQLException: ORA-00932: inconsistent datatypes: expected - got CLOB
Solution
A SELECT returning CLOB values must not use the DISTINCT clause. The simplest way to avoid DISTINCT is to disable batch attribute reading from A to B. Batch reading is a performance enhancement that attempts to simultaneously read all Bs of all previously queried As. This query uses a DISTINCT clause. Use joined reading instead, or neither joined reading nor batch attribute reading.
Because both DISTINCT and CLOBs are common, you may see this problem in other scenarios. For example, an expression like the following uses a DISTINCT clause:
SELECT DISTINCT dept.* from Department dept, Employee emp WHERE ((dept.ID = emp.DEPTNO) and (emp.name = 'Bob Smith'));
See "Relational-to-XML Mappings (toplink_mappings.xml)" for more information about batch reading and joined reading.
Problem
You may sometimes notice that merge performs an UPDATE when it should do an INSERT, or vice versa.
Solution
Merge works by first determining, for each element in the XML, whether the corresponding database row exists or not. For each row, it does an existence check.There are two known limitations with the existence check.
First, you can configure the existence check to either Check cache or Check database. You can configure this for each descriptor (mapped table) in your Mapping Workbench Project. The default is Check database, but TopLink's check database works like 'check cache first then database' for performance reasons. If a row exists in the cache but was deleted from the database (the cache is 'stale'), then you may see an UPDATE when you would expect an INSERT. You can configure caching and a WeakIdentityMap is used by default, meaning rows are only held in memory while being processed. However Java garbage collection is not controlled by the adapter, so if you insert a row, delete it in a separate process, and insert it again, all within a very short time, you may see an INSERT and then an UPDATE. One solution is to use NoIdentityMap. However, performance may suffer, and if you are doing selects on a mapped schema with complex cycles (which you should avoid!), then the adapter may become trapped in an endless loop when building the XML.
Second, there is a timing issue to doing a read first and then later an INSERT or UPDATE. If the same row is simultaneously inserted by multiple invokes, then each may do an existence check that returns false, and then all will attempt an INSERT. This does not seem realistic, but the following scenario did come up:
A polling receive reads 100 employee rows and their departments from database A. With maxRaiseSize set to 1, 100 business process instances were initiated. This led to 100 simultaneous invokes to database B, one for each employee row. No problems were encountered when existence checking on employee, but some employees had the same department. Hence many of the 100 invokes failed because the existence checks on department were more or less simultaneous.
There are two solutions to this problem. The first is to avoid it. In a data synchronization-style application, setting maxRaiseSize to unlimited will boost performance and eliminate this problem. A second solution is to retry the merge in your BPEL process. Optimistic lock and concurrency exceptions are common, and the best solution is usually to wait and try again a short time later.
Problem
Child records found integrity violation with DeletePollingStrategy.
When deleting rows, you must be aware of integrity constraints. For example, if DEPARTMENT has a one-to-many relationship to EMPLOYEE, that means DEPTID is a foreign key on EMPLOYEE. If you delete a DEPARTMENT record, but not its employees, then DEPTID will become a broken link and this can trigger an integrity constraint.
This problem occurs because you imported a table by itself and did not import its related tables. For example, if you import only the DEPARTMENT table from the database and not the EMPLOYEE table, which has an integrity constraint on column DEPTID, then the database adapter does not know about EMPLOYEE and it cannot delete a record from DEPARTMENT. You will receive an exception.
Solution
Make sure you import the master table and all its privately owned relationships. Or set the constraint on the database to CASCADE for deletions, or use a nondelete polling strategy.
Make sure that the one-to-many relationship between DEPARTMENT and EMPLOYEE is configured to be privately owned. It is by default, but if the above fails, check the run-time X-R mappings file. See "Relational-to-XML Mapping" for more information.
If the problem is not this simple, OracleAS TopLink supports shallow/two-phase inserts (but does not support this for DELETE). For example, if A has a foreign key pointing to B, and B has a foreign key pointing to A, then there is no satisfactory order by which you can delete both A and B. If you delete A first, then you will orphan B. If you delete B first, then you will orphan A. The safest DELETE is a two-phase DELETE that performs an UPDATE first as follows:
UPDATE B set A_FK = null; DELETE from A; DELETE from B;
Problem
When you execute a query, you may get the correct number of rows, but some rows appear multiple times and others do not appear at all.
This behavior is typically because the primary key is configured incorrectly. If the database adapter reads two different rows that it thinks are the same (for example, the same primary key), then it will write both rows into the same instance and the first row's values will be overwritten by the second row's values.
Solution
Open ApplicationSources > TopLink > TopLinkMappings. In the Structure window, double-click PHONES. On the first page, you should see Primary Keys. Make sure that the correct columns are selected to make a unique constraint.
Save and then edit the database partner link.
Click Next to the end, and then click Finish and Close.
Open your toplink_mappings.xml file. For the PHONES descriptor, you should see something like this:
<primary-key-fields> <field>PHONES.ID1</field> <field>PHONES.ID2</field> </primary-key-fields>
Problem
Importing a table from a database on one machine and also importing a table with the same name, and the same schema name, from a database on another machine raises an error.
Solution
Create one project against database #1 and model the adapter service. Next create a second project against database #2 and model the adapter service. (Because the databases are on different machines, you use different database connections.) Then create a third project, but do not run the Adapter Configuration Wizard. Instead copy the BPEL artifacts (WDSL, XSD, toplink_mapings.xml) from projects one and two. Deploy only the third project.
If the two tables are identical, or if the data you are interested is identical, then you need not follow the preceding procedure.
Problem
In the Adapter Configuration Relationship Wizard, all elements of the primary key appear and cannot be removed. Therefore, a foreign key referring to only part of the composite primary key cannot be created.
Solution
Because foreign key constraints must map to every part of the primary key (not a subset), there is no solution. The database adapter allows a foreign key only with a corresponding primary key at the other end.
The wizard will not let you create an ambiguous relationship. For example, assume that a PurchaseOrder has a 1-1 billTo relationship to a Contact. And for uniqueness, the primary key of Contact is name and province. This means PurchaseOrder must have two foreign keys (bill_to_name and bill_to_province). If there is only one foreign key (bill_to_name), then the wizard will not allow you to create that ambiguous 1-1 relationship. Otherwise the same purchase order could be billed to multiple people.
The BFILE, USER DEFINED, OBJECT, STRUCT, VARRAY, and REF types are not supported.
Because a table may be used for other services inside the same project, it cannot be deleted within the interface. No problems occur if the unneeded table remains as part of your project.
Problem
When you run the Adapter Configuration Wizard, any changes that affect the TopLink project (importing tables, creating or removing mappings, specifying an expression, and so on) are applied immediately, and are not undone if you cancel the wizard.
Solution
If you remove one or more of the autogenerated relationships and later want to get them back, you must reimport the tables containing the corresponding database constraints.
Problem
The database adapter can become unstable if, within the same wizard session, you remove a relationship and then immediately create a relationship with the same name.
Solution
You can do one of the following:
Give the new relationship a different name from the one you removed.
Finish the wizard after you remove the first relationship. Then start the wizard again in edit mode to add the new relationship, using the same name as the deleted relationship.
Problem
JDeveloper does not currently support importing object tables. If you try to import an object table, then you will see the following message: "The following tables were 'Object Tables' and aren't supported offline."
Solution
There is currently no workaround for this problem.
Problem
If tables are imported one at a time, relationships will not be generated even if foreign key constraints exist on the database.
Solution
Relationship mappings can be autogenerated only if all the related tables are imported in one batch. When importing tables, you can select multiple tables to be imported as a group. If you have related tables, then they should all be imported at the same time.
Problem
If you try to create a relationship that has the same name as the primary key field name, then you will encounter a problem in which the PK field becomes unmapped.
Solution
To add the PK mapping back manually, follow these instructions:
Open the Java source for the descriptor you want to add the mapping to (for example, Movies.java).
Add a new Java attribute appropriate for the field to which you are mapping. For example, if the PK of the Movies table is a VARCHAR field named TITLE, then create a new attribute: "private String title;"
Save the Java file.
Click on the TopLink Mappings node in the Applications - Navigator pane; then choose the Descriptor from the TopLink Mappings - Structure pane. You will see the newly created attribute in the Descriptor as unmapped (in this example, title).
Right-click the new attribute and select Map As > Direct To Field.
Double-click the new attribute. The TopLink Mappings editor should appear in the main JDeveloper window. Change the database field to match the PK field on the database (in this example, TITLE).
Click the Descriptor in the TopLink Mappings - Structure pane. Ensure that the PK field has a checkbox next to it in the Primary Keys list.
Run the Adapter Configuration Wizard again and continue with the rest of the wizard.
The following sections describe possible issues and solutions when using the database adapter for stored procedures.
Problem
Using an unsupported parameter type in the chosen API is a common problem. In the BOOLEAN example described in "Support for PL/SQL BOOLEAN", the procedure BOOLPROC has a single parameter, B, whose type is PL/SQL BOOLEAN, which is not supported. When the XSD is generated, you will see a WSDL write error indicating that the database type is either not supported or is not implemented.
To generate an XSD for APIs containing parameters whose types are user-defined, those types must first be defined in the database and be accessible through the associated service connection. This error also occurs if such types have not been created (that is, implemented) in the database or if the database is inaccessible.
Solution
Ensure that only supported datatypes are used as types for parameters when choosing an API. If the types are user-defined, check to ensure that the types are defined in the database and that the database is accessible when the attempt to generate the XSD is made.
Problem
When the type of one or more of the parameters in the chosen API is a user-defined type that belongs to a different schema, a design-time problem can occur. Assume type OBJ is created in SCHEMA2, as in
CREATE TYPE OBJ AS OBJECT (X NUMBER, Y VARCHAR2 (10));
And, a procedure is created in SCHEMA1 that has a parameter whose type is SCHEMA2.OBJ, as in
CREATE PROCEDURE PROC (O SCHEMA2.OBJ) AS BEGIN … END;
If you attempt to create the XSD for procedure PROC, you will see an error message similar to the following:
Error while writing wsdl file D:\OraBPEL\integration\jdev\mywork\Workspace\Test\Schema1.wsdl. Exception: WSDLException: faultCode=OTHER_ERROR: The datatype, OBJ, which belongs to the schema, SCHEMA2 is currently not supported. The datatype must belong to the same schema as the stored procedure.
Solution
This is a known limitation of the XSD generator. Thus the preceding procedure is not supported at this time, although the procedure declaration is legal, provided that the appropriate privileges to access object OBJ have been granted to SCHEMA1.
Problem
A mismatch between the formal parameters provided by the instance XML and the actual parameters that are defined in the signature of the stored procedure is a common run-time problem. When this type of error occurs, the Invoke activity that tried to execute the stored procedure will fault, as shown in Figure A-1.
Figure A-1 Example of a Faulted Invoke Due to MIsmatched Parameters
The bindingFault has three parts—code, summary, and detail. The information for these parts comes from the java.sql.SQLException that gets thrown by JDBC when it attempts to execute the stored procedure. The code is the ORA error number, seen in Figure A-1 as 6550 and as ORA-06550 in the summary and detail parts. The summary includes an adapter-specific error message followed by the message from the SQLException and a suggested resolution to the issue. The detail contains just the message from the SQLException.
As shown in Figure A-1, the ADDEMPLOYEES stored procedure failed to execute due to "wrong number or types of arguments" passed into the API. Possible causes for this problem include:
An element corresponding to one of the required parameters was not provided in the instance XML (thus, the wrong number of arguments was passed into the stored procedure).
Solution: Add the necessary element to resolve the issue.
More elements than were specified in the XSD were included in the instance XML.
Solution: Remove the extra elements from the XML.
The XSD does not accurately describe the signature of the stored procedure. For example, if the type of one of the parameters were to change and the XSD was not regenerated to reflect that change, a type mismatch can occur between the db:type of the element and the new type of the modified parameter.
Solution: Ensure that the parameters match the signature of the API, as indicated in the summary part of the bindingFault.
Problem
A bindingFault can also occur if the stored procedure is not defined in the database when an attempt to execute it is made. In this example, the ADDEMPLOYEES API is invoked, but fails to execute because it is not defined. The Invoke activity will fault, as shown in Figure A-2.
PL/SQL is revealing that "... identifier ADDEMPLOYEES must be declared," which is an indication that the stored procedure may not be defined in the database. This can occur, for example, if the procedure was dropped sometime between when the process was deployed and when the procedure was invoked. This can also occur if the required privileges to execute the stored procedure have not been granted.
Solution
Ensure that the API is defined in the database, as indicated in the summary, and that the appropriate privileges to execute that procedure have been granted.
Some run-time errors can occur if the instance XML does not conform to the XSD generated for the chosen API. XML validation can be enabled in the partner link that coincides with the execution of the API. Edit the partnerLinkBinding in the BPEL suitcase located in your process bpel.xml file, as shown in bold:
<partnerLinkBinding name=ÓPROCÓ>
<property name=ÓwsdlLocationÓ>Proc.wsdl</property>
<property name=ÓvalidateXMLÓ>true</property>
</partnerLinkBinding>
Adding the validateXML property and setting it to true turns on XML validation for all instance XML passed into the service associated with the partner link that executes the API.
XML validation can also be enabled globally in Oracle BPEL Console. Click Manage BPEL Domain and look for the validateXML property. Setting the value to true causes all XML to be validated. Turning on XML validation helps catch and avoid problems that are associated with the instance XML (rather than the adapter run time.)
The following sections describe possible issues and solutions.
If you later rerun the Adapter Configuration Wizard and change a previously specified logical name to a different name, both the old and new logical names appear in the bpel.xml file. You must manually edit the bpel.xml file to remove the old logical name.
While the Native Format Builder wizard does not restrict you from creating native schema file names with spaces, it is recommended that your file names do not have spaces in them.
This section describes common user errors.
On the Adapter Configuration Wizard - Messages page (Figure 19-5), you can select the Native format translation is not required (Schema is Opaque) checkbox. Opaque cannot be selected in only one direction. Opaque must be selected in the both inbound and outbound directions.
Messages have a different meaning based on whether they are inbound or outbound. For example, assume you make the following selections:
Select 2 from the Publish Messages in Batches of list (Figure 19-3) in the inbound direction.
Select 3 from the Number of Messages Equal list (Figure 19-7) in the outbound direction.
If an inbound file contains two records, it is split (debatched) into two messages. However, because 3 was specified in the outbound direction, a file is not created. This is because there are not three outbound messages available. Ensure that you understand the meaning of inbound and outbound messages before selecting these options.
If the OracleAS Adapter for Files or the OracleAS Adapter for FTP is not able to read or get your file, respectively, it may be because you selected to match file names using the regular expression (regex), but are not correctly specifying the name (Figure 19-3). See Table 19-2 for details.
You may have content that does not require translation (for example, a JPG or GIF image) that you just want to send "as is." The file is passed through in base-64 encoding. This content is known as opaque. To do this, select the Native format translation is not required (Schema is Opaque) checkbox on the Adapter Configuration Wizard - Messages page (Figure 19-5). If you select this check box, you do not need to specify an XSD file for translation.
The inbound directory must exist for the OracleAS Adapter for Files or the OracleAS Adapter for FTP to read or get your file, respectively.
If the FTP Adapter cannot connect to a remote host, ensure that you have configured the Oracle_Home\integration\orabpel\system\appserver\oc4j\j2ee\home\application-deployments\default\FtpAdapter\oc4j-ra.xml deployment descriptor file for adapter instance JNDI name and FTP server connection information. See "OracleAS Adapter for FTP for Get File Concepts" for instructions.
You cannot use completely static names such as po.txt for outbound files. Instead, outgoing file names must be a combination of static and dynamic portions. This is to ensure the uniqueness of outgoing files names, which prevents files from being inadvertently overwritten. See "Specifying the Outbound File Naming Convention" for instructions on creating correct outbound file names.
Two header files are created in the Applications Navigator after you finish running the Adapter Configuration Wizard in both directions:
typeAdapterInboundHeader.wsdl
Provides information such as the name of the file being processed and its directory path, as well as data about which message and part define the header operations
typeAdapterOutboundHeader.wsdl
Provides information about the outbound file name
where type is either ftp or file.
You can define properties in these header files. For example, you can specify dynamic inbound and outbound file names through use of the InboundHeader_msg and OutboundHeader_msg message names in the typeAdapterInboundHeader.wsdl and typeAdapterOutboundHeader.wsdl files, respectively.
You can also set header variables that appear in the BPEL process file. Header variables are useful for certain scenarios. For example, in a file propagation scenario, files are being moved from one file system to another using the OracleAS Adapter for Files. In this case, it is imperative that you maintain file names across the two systems. Use file headers in both the directions and set the file name in the outbound file header to use the file name in the inbound file header.
See the online help with the Adapters tab for more information.
The Adapter Configuration Wizard - File Modification Time window (Figure 19-11) prompts you to select a method for obtaining the modification times of files on the FTP server.
You must perform the following procedure to obtain this information:
Determine the modification time format supported by the FTP Server by running the command mdtm or ls -al (whichever is supported by the operating system).
Determine the time difference between the system time (time on which Oracle BPEL Server is running) and the file modification time. Obtain the file modification time by running either mdtm or ls -al on the FTP server.
Manually add the time difference to the bpel.xml as a property:
<activationAgents> <activationAgent ...> <property name="timestampOffset">2592000000</property>
Specify the Substring Begin Index field and End Index field values that you determine by running the mdtm or ls -al command on the FTP server.
The following sections describe possible issues and solutions.
The following sections describe possible issues and solutions for inbound errors when using the OracleAS Adapter for Advanced Queuing.
Sample error:
<timestamp> <WARN> <default.collaxa.cube.activation> <AdapterFramework::Inbound>
JNDI lookup of 'eis/AQ/aqSample2' failed due to: eis/AQ/aqSample2 not found
<timestamp> <ERROR> <default.collaxa.cube.activation> <AdapterFramework::Inbound>
Error while performing endpoint Activation: ORABPEL-12510
Unable to locate the JCA Resource Adapter via WSDL port element jca:address.
The Adapter Framework is unable to startup the Resource Adapter specified in the
WSDL jca:address element: {http://xmlns.oracle.com/pcbpel/wsdl/jca/}address:
location='eis/AQ/aqSample2'
Problem
It is likely that either 1) the Resource Adapters RAR file has not been deployed successfully to the OC4J Application server or 2) the 'location' attribute in $J2EE_HOME/application-deployments/default/deployed-adapter-name /oc4j-ra.xml has not been set to eis/AQ/aqSample2. In the last case you might have to add a new connector-factory entry (connection) to the oc4j-ra.xml. Correct this and then restart the BPEL/OC4J Application Server
Solution
Look for the file $J2EE_HOME/application-deployments/default/aqAdapter/oc4j-ra.xml.
This file should be created when the adapter is deployed, which occurs the first time Oracle BPEL Process Manager is started. If the adapter is undeployed for some reason, deploy the adapter with the following command, then follow step 2:
java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome -deployconnector -file <path to AQAdapter.rar> -name AqAdapter>
If $J2EE_HOME/application-deployments/default/aqAdapter /oc4j-ra.xml exists, make sure the JNDI location is defined in the oc4j-ra.xml.
For example:
<connector-factory location="eis/AQ/aqSample2" connector-name="AQ Adapter">
<config-property name="connectionString"
value="jdbc:oracle:thin:@myhost:1521:appdb2"/>
<config-property name="userName" value="scott"/>
<config-property name="password" value="tiger"/>
</connector-factory>
Sample error:
<timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> DBConnection_connect: database error while try to connect to jdbc:oracle:thin:@localhost:1521:ORCL : Io exception: The Network Adapter could not establish the connection
Solution
If the connectionString is correct, make sure the database and listener are up, then redeploy the process.
If the connectionString is not correct:
Change the connectionString in $J2EE_HOME\application-deployments\default\AqAdapter\oc4j-ra.xml.
Restart Oracle BPEL Process Manager.
Sample error:
<timestamp> <ERROR> <default.collaxa.cube.activation> <AdapterFramework::Inbound> Error while performing endpoint Activation: ORABPEL-11929 SQL error while creating managed (database) connection. SQL error while creating managed (database) connection: Error while trying to connect to database. Error while trying to connect to database using connect string "jdbc:oracle:thin:@localhost:1521:appdb2 - java.sql.SQLException: ORA-01017: invalid username/password; logon denied
Solution
Make sure you have the correct userName/passWord in $J2EE_HOME\application-deployments\default\AqAdapter\oc4j-ra.xml.
Restart Oracle BPEL Process Manager.
Sample error:
<timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> oracle.AQ.AQException: JMS-190: Queue SCOTT.AQ_SUPPORTED_ADT_IN not found at oracle.AQ.AQUtil.throwAQEx(AQUtil.java:196) at oracle.AQ.AQOracleSession.getQueue(AQOracleSession.java:720) at oracle.tip.adapter.aq.database.Queue.connect(Queue.java:102) at oracle.tip.adapter.aq.database.MessageReader.init(MessageReader.java:575)
Solution
Create the queue and redeploy the process. If this process is deployed from the samples, all queue creation scripts are located in sql/create_queues.sql under each project.
Sample error:
2005-04-20 16:10:52,695> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> oracle.AQ.AQOracleSQLException: ORA-06550: line 1, column 7: PLS-00201: identifier 'DBMS_AQIN' must be declared ORA-06550: line 1, column 7: PL/SQL: Statement ignored at oracle.AQ.AQOracleQueue.dequeue(AQOracleQueue.java:1795) at oracle.AQ.AQOracleQueue.dequeue(AQOracleQueue.java:1307) at oracle.tip.adapter.aq.database.MessageReader.readMessage(MessageReader.java:399) at oracle.tip.adapter.aq.inbound.AQActivationSpecDequeuer.run(AQActivationSpecDequeue r.java:163) at oracle.tip.adapter.fw.jca.work.WorkerJob.go(WorkerJob.java:51) at oracle.tip.adapter.fw.common.ThreadPool.run(ThreadPool.java:267) at java.lang.Thread.run(Thread.java:534)
Solution
Log on to the database using sys as sysdba, GRANT EXECUTE ON SYS.DBMS_AQIN to <username>;. No deployment is necessary because this failure occurs after the connection has succeeded, the adapter will automatically reconnect until the error is gone or the process is undeployed.
Sample error:
<timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> MessageReader_readMessage: Received TranslationException <timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> ORABPEL-11211 DOM Parsing Exception in translator. DOM parsing exception in inbound XSD translator while parsing InputStream. Check the error stack and fix the cause of the error. Contact oracle support if error is not fixable. at oracle.tip.pc.services.translation.xlators.xsd.XSDTranslator.translateFromNative(X SDTranslator.java:131)
Solution
Look for the Rejected Message and find out why it has failed translation. For instance, the message may not be XML or the XML root element maybe incorrect, or the message maybe blank. If a rejection handler has been defined for this process, look for the message in the rejection handler. Otherwise, look for the message in the default rejection handler which is located at:
Oracle_Home\integration\orabpel\domains\default\archive\jca\AQMessageRejectionHandler\rejectedMessages
For an example of how a user can define the rejection handler, look in
$ORACLE_HOME\integration\orabpel\samples\tutorials \124.AQAdapter\AQMessageRejectionHandler
Sample error:
<timestamp> <INFO> <default.collaxa.cube.activation> <AQ Adapter::Inbound>
Subscriber PriorityOneDequeuer already exists in the database. If the subscriber
does not contain the rule that you want, please undeploy the business process,
drop the subscriber with the following sql*plus command, and redeploy. DECLARE
subscriber sys.aq$_agent;
BEGIN
subscriber := sys.aq$_agent('<subscriber_name>', NULL, NULL);
DBMS_AQADM.REMOVE_SUBSCRIBER(
queue_name => '<queue_name>',
subscriber => subscriber); END;
Solution
This is not a problem if the subscriber has been generated with the rule the user expects. The adapter can create new rule-based subscribers, but cannot modify existing ones. Hence, the first time you deploy the adapter with a non-null value for MessageSelectorRule, a subscriber will be created if the consumer does not already exist, using the Consumer as the subscriber and the MessageSelectorRule as the rule. This message would appear in any subsequent redeployment or restart of Oracle BPEL Process Manager.
You can determine if the rule is what you want for the subscriber by entering the following SQL command:
SQL> select name, rule, queue from AQ$RuleBased_Raw_In_R; NAME ------------------------------ RULE -------------------------------------------------------------------------------- QUEUE ------------------------------ PRIORITYONEDEQUEUERpriority = 1 RULEBASED_RAW_IN
As a general note, problems in the outbound direction are often not caught at deployment time, because an outbound thread is only activated if there is a message going to outbound.
Sample error:
Adapter Framework unable to create outbound JCA connection.
file:/C:/050420/integration/orabpel/domains/default/tmp/.bpel_File2AQBLOB_
1.0.jar/EnqueueBlobPayload.wsdl [ Enqueue_ptt::Enqueue(opaque) ] - : The Adapter
Framework was unable to establish an outbound JCA connection due to the following
issue: ORABPEL-12510
Unable to locate the JCA Resource Adapter via WSDL port element jca:address.
The Adapter Framework is unable to startup the Resource Adapter specified in the
WSDL jca:address element: {http://xmlns.oracle.com/pcbpel/wsdl/jca/}address:
location='eis/AQ/aqSample3'
The reason for this is most likely that either 1) the Resource Adapters RAR file has not been deployed successfully to the OC4J Application server or 2) the 'location' attribute in $J2EE_HOME/application-deployments/default/deployed-adapter-name /oc4j-ra.xmlhas not been set to eis/AQ/aqSample3. In the last case you might have to add a new 'connector-factory' entry (connection) to oc4j-ra.xml. Correct this and then restart the BPEL/OC4J Application Server
Solution
See the solution section for the same problem in the inbound section.
2005-04-20 18:41:40,570> <ERROR> <default.collaxa.cube.ws> <AdapterFramework::Outbound> file:/C:/050420/integration/orabpel/domains/default/tmp/.bpel_File2AQBLOB_ 1.0.jar/EnqueueBlobPayload.wsdl [ Enqueue_ptt::Enqueue(opaque) ] - Could not invoke operation 'Enqueue' against the 'AQ Adapter' due to: ORABPEL-12511 Adapter Framework unable to create outbound JCA connection. file:/C:/050420/integration/orabpel/domains/default/tmp/.bpel_File2AQBLOB_ 1.0.jar/EnqueueBlobPayload.wsdl [ Enqueue_ptt::Enqueue(opaque) ] - : The Adapter Framework was unable to establish an outbound JCA connection due to the following issue: ORABPEL-11929 SQL error while creating managed (database) connection. SQL error while creating managed (database) connection: Error while trying to connect to database. Error while trying to connect to database using connect string "jdbc:oracle:thin:@localhost:1521:appdb - java.sql.SQLException: Io exception: The Network Adapter could not establish the connection"
Solution
If the connectionString is not correct, do the following:
Change the connectionString in $J2EE_HOME\application-deployments\default\AqAdapter \oc4j-ra.xml.
Restart Oracle BPEL Process Manager.
If the connectionString is correct, make sure the database and listener are up. If you had enabled outbound retry, the message should be automatically retried when the database and its listener are up.To configure outbound retry, set the retryMaxCount property and retryInterval property for the partner link in bpel.xml.For example, the following configuration means 10 retries, at 60 second intervals.
<partnerLinkBinding name="EnqueueBLOBPayload">
<property name="wsdlLocation">EnqueueBlobPayload.wsdl</property>
<property name="retryMaxCount">10</property>
<property name="retryInterval">60</property>
</partnerLinkBinding>
<timestamp> <ERROR> <default.collaxa.cube.ws> <AQ Adapter::Outbound>
oracle.AQ.AQException: JMS-190: Queue SCOTT.BLOBPAYLOAD_QUEUE not found
at oracle.AQ.AQUtil.throwAQEx(AQUtil.java:196)
at oracle.AQ.AQOracleSession.getQueue(AQOracleSession.java:720)
at oracle.tip.adapter.aq.database.Queue.connect(Queue.java:102)
at oracle.tip.adapter.aq.database.MessageWriter.init(MessageWriter.java:231)
Solution
Same solution as the inbound Queue not found problem. Create the queue and redeploy the process. If this process is deployed from the samples, all queue creation scripts are located in sql/create_queues.sql under each project.
Sample error:
file:/C:/050420/integration/orabpel/domains/default/tmp/.bpel_File2AQBLOB_ 1.0.jar/EnqueueBlobPayload.wsdl [ Enqueue_ptt::Enqueue(opaque) ] - : The Adapter Framework was unable to establish an outbound JCA connection due to the following issue: ORABPEL-11929 SQL error while creating managed (database) connection. SQL error while creating managed (database) connection: Error while trying to connect to database. Error while trying to connect to database using connect string "jdbc:oracle:thin:@localhost:1521:appdb2 - java.sql.SQLException: ORA-01017: invalid username/password; logon denied.
Solution
Make sure you have the correct username/password in $J2EE_HOME\application-deployments\default\AqAdapter\oc4j-ra.xml.
Restart Oracle BPEL Process Manager.
Sample error:
<timestamp> <ERROR> <default.collaxa.cube.ws> <AQ Adapter::Outbound>
oracle.AQ.AQOracleSQLException: ORA-06550: line 1, column 7:
PLS-00201: identifier 'DBMS_AQIN' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
at oracle.AQ.AQOracleQueue.enqueue(AQOracleQueue.java:1267)
Solution
Logon to the database using sys as sysdba, GRANT EXECUTE ON SYS.DBMS_AQIN to <username>;. Again, if you have retry configured for this partner link, retry automatically happens.
Sample error:
<timestamp> <ERROR> <default.collaxa.cube.ws> <AQ Adapter::Outbound> ORABPEL-11101 Translation Failure. Translation to native failed. Invalid text 'blahblah' in element: 'Root-Element'. Check the error stack and fix the cause of the error. Contact oracle support if error is not fixable. at oracle.tip.pc.services.translation.xlators.nxsd.NXSDTranslatorImpl.translateToNati ve(NXSDTranslatorImpl.java:502) at oracle.tip.adapter.aq.database.MessageWriter.translateToNative(MessageWriter.java: 1102) at oracle.tip.adapter.aq.database.MessageWriter.doEnqueue(MessageWriter.java:494)
Solution
From Oracle BPEL Console go to Instances
Click on the failed instance and select Debug
Look for the variable that is passed to the invoke activity which failed, you should notice this variable match schema definition. Backtrack in the Debug screen to find out why.
I have an AQ inbound to AQ outbound end-to-end scenario. How do I copy the priority from an inbound queue to an outbound queue?
Solution: Create both the inbound header and outbound header, and use an assign activity to copy the priority.
Create the inbound header:
Click on the Receive Activity which is linked to the AQ Inbound partnerlink.
Select the Adapters tab, choose Header Variable, and click on the flashlight icon.
Click on Variables and select Create.
Enter a name such as inbound_header.
Click on Message type and click on the flashlight icon.
If payloadHeader is not required (most cases): In the type chooser, drill down through Type Explore, Message Types, Partner Links, <inbound partnerlink name>, <inbound service.wsdl>, Imported WSDL, aqAdapterInboundHeader.wsdl, Message Types, and Header. Skip to step 8.
If a payloadHeader IS required, only if PayloadHeaderRequired="true" in the JCA operation section of <service.wsdl>: In the type chooser, drill down through Type Explore, Message Types, Partner Links, <inbound partnerlink name>, Message Types, and Header_msg.
Click OK to exit the type chooser.
While the variable is still highlighted, click OK to pick this variable.
The variable now appears as the header variable. Click OK to exit the Receive Activity.
Create the outbound header:
Click on the Invoke activity which is linked to the AQ outbound partner link.
Select the Adapters tab, choose Header Variable, and click on the flashlight icon.
Click on Variables and select Create.
Enter a name such as outbound_header.
Click on Message type and click on the flashlight icon.
If payloadHeader is not required (most cases): In the type chooser, drill down through Type Explore, Message Types, Partner Links, <inbound partnerlink name>, <inbound service.wsdl>, Imported WSDL, aqAdapterInboundHeader.wsdl, Message Types, and Header. Skip to step 8.
If a payloadHeader IS required, only if PayloadHeaderRequired="true" in the JCA operation section of <service.wsdl>: In the type chooser, drill down through Type Explore, Message Types, Partner Links, <inbound partnerlink name>, Message Types, and Header_msg.
Click OK to exit the type chooser.
While the variable is still highlighted, click OK to pick this variable.
The variable now appears as the header variable. Click OK to exit the Receive Activity.
In an Assign activity:
Click on the Copy Rules tab and select Create.
On the From side: drill down to priority in inbound header variable.
On the To side: drill down to priority for the outbound header variable.
Click OK to exit Create Copy Rule
Click OK to exit the Assign activity.
I redefined the adapter WSDL by stepping through the wizard again. Why doesn't my service.wsdl change?
Solution:
It did work, but Jdeveloper didn't refresh the file properly. Close the service.wsdl and open it again.
I redefined the adapter service wsdl using the wizard. But at deployment time, I got the following error:
Process "AQSupportedADTTypes" (revision "1.0") compilation failed.<timestamp> <ERROR> <default.collaxa.cube.engine.deployment>
<CubeProcessLoader::create> BPEL validation failed.
BPEL source validation failed, the errors are:
[Error ORABPEL-10007]: unresolved messageType
[Description]: in line 16 of
"C:\050420\integration\orabpel\domains\default\tmp\.bpel_AQSupportedADTTypes_
1.0.jar\AQSupportedADTTypes.bpel", WSDL messageType
"{http://xmlns.oracle.com/pcbpel/adapter/aq/Enqueue/}Header_msg" of variable
"out_header" is not defined in any of the WSDL files.
[Potential fix]: Make sure the WSDL messageType
"{http://xmlns.oracle.com/pcbpel/adapter/aq/Enqueue/}Header_msg" is defined in
one of the WSDLs referenced by the deployment descriptor.
Solution:
When you redefine the adapter service wsdl, you also need to redefine the header variables. The creation of header variables the ÒinputÓ element in the JCA binding section which defines the header.
For example:
<input> <jca:header message="tns:Header_msg" part="Header"/> </input>
When the adapter service is redefined, the old wsdl file is overwritten. Simply delete the old header variables and recreate them.
Sample error:
<timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> MessageReader_readMessage: Received TranslationException <timestamp> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> ORABPEL-11211 DOM Parsing Exception in translator. DOM parsing exception in inbound XSD translator while parsing InputStream. Check the error stack and fix the cause of the error. Contact oracle support if error is not fixable. at oracle.tip.pc.services.translation.xlators.xsd.XSDTranslator.translateFromNative(X SDTranslator.java:131)
Solution:
Look for the Rejected Message and find out why it has failed translation. The message may not be XML or the XML root element maybe incorrect, or the message may be blank. If a rejection handler has been defined for this process, look for the message in the rejection handler. Otherwise, look for the message in the default rejection handler which is located at:
ORACLE_HOME\integration\orabpel\domains\default\archive\jca\AQMessageRejectionHandler\rejectedMessages
For an example of how a user can define the rejection handler, look in
ORACLE_HOME\integration\orabpel\samples\tutorials\124.AQAdapter\AQMessageRejectionHandler
I have a new adapter *.RAR file; how do I redeploy the adapter?
Save a copy of $J2EE_HOME\application-deployments\default\AqAdapter \oc4j-ra.xml so you have your endpoint information.
Undeploy the adapter by entering the following command:
java -jar $JE22_HOME\admin.jar ormi://localhost admin welcome -undeployconnector -name AqAdapter
Deploy the new *.RAR file by entering the following command:
java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome -deployconnector -file <rarfile> -name AqAdapter
Modify $J2EE_HOME\application-deployments\default\AqAdapter \oc4j-ra.xml to add your endpoints.
Restart Oracle BPEL Process Manager. You should not have to redeploy your business processes.
Subscriber already exists when using MessageRuleSelector
<timestamp> <INFO> <default.collaxa.cube.activation> <AQ Adapter::Inbound>
Subscriber PriorityOneDequeuer already exists in the database. If the
subscriber does not contain the rule that you want, please undeploy the
business process, drop the subscriber with the following sql*plus command,
and redeploy.
DECLARE
subscriber sys.aq$_agent;
BEGIN
subscriber := sys.aq$_agent('<subscriber_name>', NULL, NULL);
DBMS_AQADM.REMOVE_SUBSCRIBER(
queue_name => '<queue_name>',
subscriber => subscriber);
END;
Solution:
This is not a problem if the subscriber has been generated with the rule the user expects. The adapter can create new rule-based subscribers, but cannot modify existing ones. Hence, the first time you deploy the adapter with a non-null value for MessageSelectorRule, a subscriber will be created if the consumer does not already exist, using the Consumer as the subscriber and the MessageSelectorRule as the rule. This message would appear in any subsequent redeployment or restart of Oracle BPEL Process Manager.
You can determine if the rule is what you want for the subscriber by entering the following SQL command: select name, rule, queue from AQ$<QUEUE_TABLE_NAME>_R;
SQL> select name, rule, queue from AQ$RuleBased_Raw_In_R; NAME ------------------------------ RULE -------------------------------------------------------------------------------- QUEUE ------------------------------ PRIORITYONEDEQUEUER priority = 1 RULEBASED_RAW_IN
User does not have DBMS_AQIN privileges, which are required by the AQ Java API
2005-04-20 16:10:52,695> <ERROR> <default.collaxa.cube.activation> <AQ Adapter::Inbound> oracle.AQ.AQOracleSQLException: ORA-06550: line 1, column 7: PLS-00201: identifier 'DBMS_AQIN' must be declared ORA-06550: line 1, column 7: PL/SQL: Statement ignored at oracle.AQ.AQOracleQueue.dequeue(AQOracleQueue.java:1795) at oracle.AQ.AQOracleQueue.dequeue(AQOracleQueue.java:1307) at oracle.tip.adapter.aq.database.MessageReader.readMessage(MessageReader.java:399) at oracle.tip.adapter.aq.inbound.AQActivationSpecDequeuer.run(AQActivationSpecDeq ueuer.java:163) at oracle.tip.adapter.fw.jca.work.WorkerJob.go(WorkerJob.java:51) @ at oracle.tip.adapter.fw.common.ThreadPool.run(ThreadPool.java:267) at java.lang.Thread.run(Thread.java:534)
Solution:
Logon to the database using sys as sysdba, 'GRANT EXECUTE ON SYS.DBMS_AQIN to <username>;'. No deployment is necessary because this failure occurs after the connection has succeeded, the adapter will automatically reconnect until the error is gone or the process is undeployed.
Failed JNDI Lookup
<timestamp> <WARN> <default.collaxa.cube.activation>
<AdapterFramework::Inbound> JNDI lookup of 'eis/AQ/aqSample2' failed due to:
eis/AQ/aqSample2 not found
<timestamp> <ERROR> <default.collaxa.cube.activation>
<AdapterFramework::Inbound> Error while performing endpoint Activation:
ORABPEL-12510
Unable to locate the JCA Resource Adapter via WSDL port element jca:address.
The Adapter Framework is unable to startup the Resource Adapter specified in
the WSDL jca:address element:
@ {http://xmlns.oracle.com/pcbpel/wsdl/jca/}address:
location='eis/AQ/aqSample2'
Solution:
The reason for this is most likely that either:
The Resource Adapters RAR file has not been deployed successfully to the OC4J Application server
The Resource Adapters RAR file has not been deployed successfully to the location attribute in
$J2EE_HOME/application-deployments/default/deployed-adapter-name/oc4j-ra.xml has not been set to eis/AQ/aqSample2.
In this case you might have to add a new connector-factory entry (connection) to the oc4j-ra.xml file. Add the correct entry and then restart the BPEL Application Server.
How to fix:
Look for the file $J2EE_HOME/application-deployments/default/aqAdapter/oc4j-ra.xml. This file should be created when the adapter is deployed, which occurs the first time Oracle BPEL Process Manager is started. If the adapter is undeployed for some reason, deploy the adapter with the following command, then follow step 2:
java -jar $J2EE_HOME/admin.jar ormi://localhost admin welcome -deployconnector -file <path to AQAdapter.rar> -name AqAdapter
If $J2EE_HOME/application-deployments/default/aqAdapter/oc4j-ra.xml exists, make sure the JNDI location is defined in the oc4j-ra.xml file.
<connector-factory location="eis/AQ/aqSample" connector-name="AQ Adapter"> <config-property name="connectionString" value="jdbc:oracle:thin:@myhost:1521:appdb2"/> <config-property name="userName" value="scott"/> @ <config-property name="password" value="tiger"/> </connector-factory>
The following sections describe possible issues and solutions.
Problem
Due to a bug, you can experience poor JMS performance when creating or destroying connections.This can cause a slowdown in the execution of BPEL processes that have JMS data publishers associated with them.
Solution
Use the rollup patch included on the software CD. See the readme file.
Problem
The custom data publisher is not working.
Solution
Make sure that the class file has been generated and that it is in the system classpath. See the obsetenv.bat file for this definition, or the BPEL suitcase.
Ensure that you have implemented the data publisher interface.
If you compile your data publisher into the system classpath, then you must restart Oracle BPEL Process Manager. You may have made changes to the data publisher without restarting Oracle BPEL Process Manager.
It is possible that an exception is being thrown in your data publisher. Check the log file for any exceptions, or temporarily add a try/catch block around all your code. In the catch, print the stack trace. These messages will pipe to the text window that opens when you start Oracle BPEL Process Manager.
Problem
The data publisher works fine, but the business process runs very slowly.
Solution
There are a couple of options.
First, you can attempt to profile your code. The do-user-sensor-callback statistic in Oracle BPEL Console records how much time is spent publishing sensor data.
Second, you can switch from a custom data publisher to a JMS Publisher. Then, you can deploy a Message Driven Bean to the application server to publish data whenever data is sent to that particular JMS destination. This decouples data publishing from process execution.
Problem
To improve performance, I would like to cache data in my data publisher. Is this supported?
Solution
This is not supported. Data publishers should be stateless.
Problem
My data publisher works fine most of the time, but sometimes I get a weird error.
It is possible that your data publisher is experiencing concurrency issues.
Solution
Data publishers must be coded in a thread-safe manner. This means that the Java code must be thread safe as well as the utilization of resources, such as databases or files.
Problem
The data I extract is complex XML. It is difficult to work with. Can I do anything to make it simpler?
Solution
While the W3C DOM model is somewhat cumbersome, there are third-party models (such as DOM4J) that make things easier. It is easy to create a DOM4J object from its corresponding W3C DOM object. Another option is to generate JAX-B objects or schema objects for the data you extract. Then you can use the generated Java classes to manipulate data more easily.
The following sections describe possible issues and solutions.
You cannot log in to the Worklist Application if your information is not available in the identity service. Check with an administrator to verify that your user information is present in the identity system (a file based on LDAP, such as Oracle Internet Directory).
The Worklist Application gets a user's language (locale) preferences from the identity service and displays the information in that locale. If information is displayed in the wrong language, make sure that the user's preference is set to a supported locale. See "Accessing the Worklist Application in Local Languages" for more information.
The Worklist Application gets a user's timezone preference from the identity service and displays the information in this timezone. Also, the date and time is formatted to suit the language (locale) preference. Make sure that these preferences are correctly specified in the identity service. See "Identity Service" for more information.
You may see an error message that says something like "User jcooper is not permitted to perform the action Update on task Loan application for John with id...." Check if the user has permission to perform the action or if the action can be performed on the task in its current state. You can also check for the following:
The task expired between the time the user loaded the page and actually performed the action.
The task was updated by another user (such as a manager, owner, or admin) between the time the user loaded the page and actually performed the action.
On the Worklist Application home page, under the Title column, if you do not see a task listed that you expected to see, then it may have been modified by another user or by the system.
Another user, such as a manager or group member, may have modified the task by performing any of the following actions:
Complete
Suspend
Request More Information
Also, the filer of the task may have withdrawn (cancelled) the task.
The system can modify a task in the following situations:
If the process instance associated with a task was purged or archived, the task is also purged or archived and may not be accessible.
If a task expires
If a task encounters a system error such as an incorrect assignee
In most of the preceding cases, you will be able to view the task by changing the filters to a broader category (such as Any or All).
