Manual Recovery

Could somebody please tell me why a process could go into manual recovery list. One of my processes is getting into the manual recovery list and am not able to see its activity flow. The console keeps saying "Try again".
Thanks,
Valli.

Could somebody help me with the below.
Thanks,
Valli.

Similar Messages

Process not getting correlated and going into manual recovery stage

Hi
I have developed a bpel process which implements correlation. I have unit tested it and is working fine. But am encountering issues in case of load.
The process which should correlate to the running process is going into manual recovery and the correlation is not happening. Whenever is restart the managed server, and then recover the instance things are getting completed and correlation is happening.
Can some one suggest what might be the problem in this case
Thanks in advance

Sumit,
This occurs because your process has not dehydrated to the dehydration store yet.
The process has not failed but it is waiting for a response from some partner link in your BPEL process. This can be common when calling async ESBs and the ESB fails.
To try and debug this you will need to look at the domain.log and see if any error is generated. Have a look at your BPEL process and see what partner link cal cause a failure yet not send a response back.
Is the DB adapter the only partner link or are there others?
cheers
James

How do I send instance for manual recovery at run time.

Hi
I have a BPEL process within which I am trying to handle a business error. I understand using the default-policies on the application server I can send a message for manual recovery. But is it possible to force an instance into the manual recovery queue in the event of a handled error?
I have previosuly used the default policies to route remote/binding faults to the activities tab (manual recovery) tab and the users find this useful to adjust XM land retry, re-throw etc. But can we do the same for errors handled within the BPEL. So if I have a catch all within my process how would I send the instance to this manual recovery queue.
Thanks
Rich

I hate it when after an hour's searching I post a question
and then find the answer ten minutes later...
"Current VI's Path" on the file IO palette...
Bob

Duplicate Record - Perform Manual Recovery

hi,
I am facing . I will explain the scenario.
I have 10 XML files, each containing 5000 thousands records.
I am writing all the XML file date into database table as below.
     Write operation
XML Flies      ------------------> Database Tables
[ File Adapter ]     [Database Adapter]
Suppose BPEL is processing arround 500 records of the 1'st file and
rest of them are going into manual recovery.
The problem is when all the files are getting processed again BPEL is
processing first 500 records of 1st file again. As a result duplicated
entries of 500 records are getting created in the database table.
Is there any way, so that BPEL second time starts processing from 501 th
record of the first file ?
Regards,
Subhra

Hi Subhra,
you could configure the FileAdapter debatching to say only raise 100 records at a time as part of one xml payload/BPEL instance. That way on failure less records will need to be retried. Performance may be a little more stable as a result too.
As for on retry getting unique constraint exceptions, I would try using 'merge' instead of 'insert'. Merge does an existence check first and if your payload sizes are 100+ the performance hit is very minimal, as it does a single existence query for all rows at once.
Thanks
Steve

Mark instance for manual recovery

Is there any way I can programmatically set my instance for manual recovery without fault policy ?
I.e
I would like to suspend my process for a certain period of time and manually invoke from the activity where i left ..
I do not want to use wait because, I would like to manually recover my instance. Also wait activity consumes a thread of scheduler that causes perfomance issues.
Please let me know if you have any idea..
Thanks,
-Sridhar

Hi Sridhar
Send it to a manual task, then reissue manually from the worklist. You can put a timeout on the worklist entry too so that the instance can be restarted automatically after a period.
Tony

Do instance id #s change on manual recovery?

We are having instance which go to the manual recovery list, and so we recover them.
Then on the log we see these types of messages:
<INFO> <default.collaxa.cube.engine> <CubeEngine::expireActivity> Instance/activity not found, next expiration attempt (?/5) for activity "130130-BpInv1-BpTry2.10-1" scheduled for "November 14, 2007 8:32:43 AM GMT"
These messages are referencing instances that don't exist on the server, maybe an instance number less(in this example 130129) or instance number more(in this example 130131) do exist, but this one doesn't.
So we are thinking if this instance gets a new number id once it is recovered. Does anyone know about if this is true or false?

may i know the release number of bpel engine? obversion.sh or obversion.bat should give this info.
are there any other errors (rollback exceptions) in the log file? looks like the invoke failed due to some system exception, the transaction rolled back but the retry gets scheduled...we fixed similar issue in 10.1.3.3.

Manual Recovery of RAC

Hi,
I am cloning from 10g RAC to single node. For this, I am trying to recover from the
Hot backup of RAC database.
I have take the archives from both the nodes, while backup was in progress.
But during recovery, I am getting messed up with Thread1 and Thread 2 archives.
Is there any funda behind RAC manual recovery ??
Thanks
Sunil.

What do you mean by "I am getting messed up with Thread1 and Thread 2 archives." ?
The THREAD# should be part of the log_archive_format so that you can identify the archivelogs of each thread.
At the RECOVER DATABASE session, if Oracle starts from Thread#1, it can identify the archivelog for the Thread#1 file. However, for the first archivelog from Thread#2, it may not be be able to identify the archivelog file name but it DOES provide you the expected Sequence#. So, you can enter the archivelog from Thread#2 corrresponding to that Sequence#. Subsequently, Oracle should be able to identify and apply archivelogs from both Threads.

Executing Instances waiting for pending manual recovery

Hi,
We are using SOA Suite 10.1.3.3.1.
As part of error handling design, we have configured the fault policy such that BPEL flows will go to manual recovery in case of PL errors. From BPEL console we can retry/abort these instances. Is it possible to do the same using BPEL client API.
Thanks

My understanding was that if I use the cancel() method all activities for this instance are cancelled too.
I don't want to manual delete this messages. I'm searching for a bugfix or an automatic workaround.
Is this a bug in the bpel engine?? see java-api-doc for this method.
void cancel()
throws ServerException
Cancels the instance. All active activities that belong to this instance will also be cancelled.
When an activity is cancelled, the performer of the activity is notified of the cancellation and is given an opportunity to rollback or cancel any work that has already been done on behalf of the activity. Since this clean-up procedure can take an indeterminate amount of time, cancelling an instance may not be instaneous and could result in new activities being activated.
Throws:
ServerException - if there is a problem in locating the instance in the process domain or if the requested action is not permitted (the instance this handle is referring to may have been changed in the meantime).
Edited by: harald.reinmueller on May 15, 2009 11:42 AM

Manual Recovery of BPEL Instances -- Failed

Hi
I am facing some issue related to Manual Recovery Process. All my BPEL instances are sitting in the Manual Recovery Mode, when I try to Recover / Call the instances, the console if failing to deliver the Conversation ID.
Can any one help me out..
Regards
Kirthi

Hi,
When I try to recover the instance that is waiting for manual recovery, I didn't see anything happening.
Also the the fault policy is active and working fine during the retry intervals. That means If I disable one of the webservices and enable them during the retry it is success after some failure retries.
Any ides why the recovery not working in SOA 10.1.3.3
--Khaleel

Auto retry for the instances under manual recovery

Hi
I have a situation where i need to refire all the instances which are in activities tab [because of manual intervention in the fault policy] at regular intervals.
Checked the documentation where it says in 10.1.3.4 we can configure a time frame where it will refire all the instances which are in recover tab under administration.
Tried out that option but it is not taking the instacnes which are in activities tab
Can some one suggest a workaround for this
Thanks
Vamsi

Hi,
When I try to recover the instance that is waiting for manual recovery, I didn't see anything happening.
Also the the fault policy is active and working fine during the retry intervals. That means If I disable one of the webservices and enable them during the retry it is success after some failure retries.
Any ides why the recovery not working in SOA 10.1.3.3
--Khaleel

Perform Manual Recovery and Refresh Alarm Table in BPEL Console

Hi,
does anybody know what these options in BPEL Console (BPEL Processes tab) are for ? Thanks.
- Refresh Alarm Table. What is this for ? Why do you need it ?
- Perform Manual Recovery. Can you tell me an example when I can use this option ?

Hi,
does anybody know what these options in BPEL Console (BPEL Processes tab) are for ? Thanks.
- Refresh Alarm Table. What is this for ? Why do you need it ?
- Perform Manual Recovery. Can you tell me an example when I can use this option ?

BPEL Manual Recovery

I am using SOA 11g. I have a one way bpel process starting from JMS Consumer till a file adaoter write. On any catchall scenario, the instance goes to manual recovery and the state of the instance shows as "Running" and this state remains for a long time. Any suggestions to over come this?

Arik,
On a selection fault which is not handled out of seedeed faults, it is going to catchall block. In catch all block, I am having an assign for AIAAsyncErrorHandlingBpelProcess variable and invoke to AIAASyncErrorHandlingBpelProcess followed by throw which throws the AIAAsync Input variable. So at runtime, the selection fault is leading the process to catchall and the isntance shows as faulted since we have throw but the process state shows Running and goes to manual recovery. Can you please suggest on this.

Monitoring the manual recovery queue

Recently we have had a large number of transactions going into the manual recovery queue on our produbion BPEL app server. I have tuend the thread performance and this has helped.
However we would like to setup a notification when we get something in the manaul recovery queue. Is there a way to monitor the manual recovery queue for certain processes, and if so, how?

You could write a BPEL process that wraps a databse adapter that monitors rows in the hydration store, or use Java Embedding and the API;s to monitor the messages ending on the queue. The API guide has some details on how to do this.
Pete

Callback Manual Recovery record created and never cleared

Hi Guy's,
I just noticed (meaning its been happening all along) in the Manual Recovery function of BPEL console, that under the 'callback' option, there seems to be an entry in there for most if not all BPEL processes that have ever been invoked. They don't seem to ever clear, and if I perform a manual recovery, this is the output traced to domain.log:
<2007-09-14 11:43:52,510> <DEBUG> <gmc.collaxa.cube.engine.delivery> <SOAPProtocolHandler::resolveSubscriber> trying to find callbacks of convId=MD5{6e3d428f177762ae547ed02a43caca5a}
<2007-09-14 11:43:52,513> <DEBUG> <gmc.collaxa.cube.engine.delivery> <SOAPProtocolHandler::resolveSubscriber> No callbacks are found of convId=MD5{6e3d428f177762ae547ed02a43caca5a}
<2007-09-14 11:43:52,513> <DEBUG> <gmc.collaxa.cube.engine.delivery> <DeliveryService::resolveSubscriber> No messages found for subscriber bpel://localhost/gmc/SFI_CreateExceptionTask~1.0/2500004-BpRcv1-BpSeq2.9-4 for conversation MD5{6e3d428f177762ae547ed02a43caca5a}
<2007-09-14 11:55:44,760> <DEBUG> <gmc.collaxa.cube.engine.delivery> <DeliveryService::resolveCallback> Resolving subscribers for convId bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/2500016-BpInv2-BpSeq5.15-1, msgGuid=51b8f0982742e789:-74af1a88:1150396d9bc:-7a53
<2007-09-14 11:55:44,775> <DEBUG> <gmc.collaxa.cube.engine.delivery> <SOAPProtocolHandler::resolveCallback> trying to find subscribers for convId=bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/2500016-BpInv2-BpSeq5.15-1, operation onResult, process bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/
<2007-09-14 11:55:44,777> <DEBUG> <gmc.collaxa.cube.engine.delivery> <SOAPProtocolHandler::resolveCallback> No subscribers found for convId: bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/2500016-BpInv2-BpSeq5.15-1
<2007-09-14 11:55:44,777> <DEBUG> <gmc.collaxa.cube.engine.delivery> <DeliveryService::resolveCallback> No subscribers found for message 51b8f0982742e789:-74af1a88:1150396d9bc:-7a53 for conversation bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/2500016-BpInv2-BpSeq5.15-1
<2007-09-14 11:56:11,540> <DEBUG> <gmc.collaxa.cube.engine.delivery> <DeliveryService::resolveCallback> Resolving subscribers for convId bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/2500016-BpInv2-BpSeq5.15-1, msgGuid=51b8f0982742e789:-74af1a88:1150396d9bc:-7a53
<2007-09-14 11:56:11,547> <DEBUG> <gmc.collaxa.cube.engine.delivery> <SOAPProtocolHandler::resolveCallback> trying to find subscribers for convId=bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/2500016-BpInv2-BpSeq5.15-1, operation onResult, process bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/
<2007-09-14 11:56:11,548> <DEBUG> <gmc.collaxa.cube.engine.delivery> <SOAPProtocolHandler::resolveCallback> No subscribers found for convId: bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/2500016-BpInv2-BpSeq5.15-1
<2007-09-14 11:56:11,548> <DEBUG> <gmc.collaxa.cube.engine.delivery> <DeliveryService::resolveCallback> No subscribers found for message 51b8f0982742e789:-74af1a88:1150396d9bc:-7a53 for conversation bpel://localhost/gmc/SFI_CreateChartOfAccount~1.0/2500016-BpInv2-BpSeq5.15-1
Any ideas what I might have configured incorrectly?
Thanks.

Hi Subhra,
you could configure the FileAdapter debatching to say only raise 100 records at a time as part of one xml payload/BPEL instance. That way on failure less records will need to be retried. Performance may be a little more stable as a result too.
As for on retry getting unique constraint exceptions, I would try using 'merge' instead of 'insert'. Merge does an existence check first and if your payload sizes are 100+ the performance hit is very minimal, as it does a single existence query for all rows at once.
Thanks
Steve

BPEL manual recovery - 10.1.3.3

Hi,
We have some stuck processes in our BPEL manual recovery console.
We have tried recovering messages from the console itself. However they still dont to disappear and create an instance.
I dont see anything in the logs as well.
Can you please help in getting the messages? ALso, is the payload stored anywhere?
Version is 10.1.3.3
Thanks,
Rosh

On BPEL Console, select your domain. Go To Configuration --> Logging and increase the logging level, preferably to All or DEBUG. Now try to recover and check if you find anything in logs.
On the Manual Recovery (invoke/recv/activity), when you click on conversation Id, are you able to see the right payload ?

Manual Recovery

Similar Messages

Maybe you are looking for