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

Similar Messages

Python script to automate the manual recovery of BPEL instances in SOA 11g

I have a requirement for automating the manual recovery of BPEL instances pending for recovery at a particular time. It will be called inside a cron job.
Any help will be much appreciated.
Thanks in advance,
Ravi Prakash

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

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.

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

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

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.

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 ?

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

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 ?

Restarting failed BPEL instances in production

1. Assume there are 1000 transactions per hour. If one of the 3rd party services is down (say Oracle Apps) for an hour and 1000 bpel instances have failed, How do we restart the failed 1000 instances at the same time (or in a single click)? We want to avoid the administrator going and starting each BPEL instances separately.
2. If the BPEL flow has 10 activities in the flow and all instances have failed in the 6th activity (calling Oracle Apps Adapter service), when we restart the failed instance, Will it again redo the first 5 activities or will it start exactly from where it failed?
Thanks,
Joe

You said:
1 Assume there are 1000 transactions per hour. If one of the 3rd party services is down (say Oracle Apps) for an hour and 1000 bpel instances have failed, How do we restart the failed 1000 instances at the same time (or in a single click)? We want to avoid the administrator going and starting each BPEL instances separately.
It could be that processes are restarted by the BPEL PM by itself. Otherwise the message of the instances are recorded in the dehydration store. You can recover the message from this recover area via the BPEL console. You can selected them all and recover them at once. Or you create a Java program using the BPEL API to perform this. BUT it all depends on your process design! If a process fails, it should go into the exception flow and handled by the exception process, aka error-hosipital. If processes should be re-started you must design it.
2. If the BPEL flow has 10 activities in the flow and all instances have failed in the 6th activity (calling Oracle Apps Adapter service), when we restart the failed instance, Will it again redo the first 5 activities or will it start exactly from where it failed?
It depends in the process-type; synchronous or a-synchronous. A synchronous process will fail and restarteing should be done via the calling process, because the sync process does not dehydrate. An a-sync process will de-hydrate his process state on specific aktivities; receive/invoke/wait, when a process fails it will contuniue from his last process state.

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

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

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

RECOVERY of crashed instance

I have a bpel-process like the following:
1) receive (client)
2) assign
3) assign
4) reply (client)
5) assign
6) assign
7) invoke (client callback)
A instance of this process chrashed during server-restart after 4)
After the server-restart the instance is still in status open.running but not doing anything.
How can i recover such an instance?

Harald,
You could try looking in 'Perform Manual Recovery' within the BPEL console. This can be accessed from:
1) Logging into the BPEL console
2) Select BPEL Processes tab
3) Select 'Perform Manual Recovery' Link on the Left hand side palette.
If you look under each of the tabs (invoke, callback) there may be a record for your instance (look at conversation id and bpel process). If there is, you should be able to manually recovery your instance
Hope that Helps
Dave

Manual Recovery of BPEL Instances -- Failed

Similar Messages

Maybe you are looking for