Custom Search SOABYTE here

Monday, November 8, 2010

Polling Process is Deployed but Nothing Happens

  1. Most commonly the DBAdapter is not polling because there was an exception right away, so checking the logs is a good first step.  A process can deploy but then fail as soon as it starts actually polling.  But the deploy will misleadingly report success.  Sometimes the process will appear as 'OFF' in the console, but many times the exception is marked retriable so the process is never disabled.  Clicking on the alerts tab in BPEL console should reveal any retriable exceptions currently being encountered (like table not found).  Failing that you can check the domain.log file and search for Exception, or even 'oracle.tip.adapter.db' to get specific DBAdapter logging and stack traces.
  2. Or the DBAdapter may be polling error free, executing a SQL statement every few seconds, but getting no hits.  This can be clearly seen with ACTIVATION logging set to DEBUG (see instructions at the very bottom of this wiki page, under Adapter Framework).  You will see the sql being logged every few seconds but no other meaningful logging.  This means the querying is returning no hits.
  3. First step then would be to take that sql being executed, and execute it in a new sqlplus prompt, or in SQL Worksheet in Jdeveloper.   If you get 0 rows that means rows may exist but the query as designed is not picking them up.  You may need to run through the wizard again and edit the where clause.
  4. If you get the expected number of rows, maybe you inserted some seed data in the same sql prompt but did not commit.  Try "rollback;", and execute the query again.
  5. Keep in mind that predicates like > someDate are very tricky to transcribe to a sqlplus prompt, as the bind values are difficult.  Check for any border line faults: > someDate will return 0 rows if someDate is today.
  6. Many take the same query returning rows in a sqlplus prompt as confirmation that something is suspiciously seriously wrong with the DBAdapter.   However there is more yet.  You may be querying against the wrong database.  Or the wrong user on the same database.  When you deploy a process which database you actually connect to is hidden behind some indirection.  There is connection info in the wsdl, but also a jndi name of a DBAdapter instance deployed to the app server.  This instance if deployed takes precedence over what is in the wsdl.  And it has its own optional connection info.  There is even another level of indirection, as the DBAdapter instance in turn points to a data-sources.xml instance which is the ultimate source for connection info.  Best would be to examine the Deployment section in the DBAdapter guide and track exactly what database/schema the query is getting executed against.  You should be able to see either the connection url and username or the datasource name from the DEBUG logging.
  7. The previous is normally it, but there may be a previously deployed rival process, even the same process but with a different name or deployed on another machine, that is processing all the rows before this process can.  Unused polling processes should be undeployed or turned off as they run continuously.
  8. Rarely, the DBAdapter may be rejecting the messages.  However this should only ever occur if you set the advanced option SchemaValidation to true and make the auto-generated xsd more restrictive than the relational schema's constraints.
  9. Finally there is a commonly overlooked explanation, that the DBAdapter is being rude (or some other state of being normally attributed only to humans).  This is kind of like message rejection but completely malicious.  It is reading your rows but not doing or logging anything.


Post a Comment

Blogger Profile