This content has been marked as final. Show 4 replies
I'm not having solution, but having suggestion. To solve this problem you can start the applications one by one. For example start the ApplicationServer first then BPEL Engine and then EBS. You need to start your dequeing application at last. By doing this all your applications will be ready to serve before consuming the message.
Second suggestion is to disable dequeue message from the queue. AQ provides option to disable dequeing the message(may be other queuing technology might have similar settings), temporarily set the property to disable dequeue. Once all the applications are up then enable the dequeue property.
A slightly different approach would be to disable the relevant consumer SOA composites before you shut down the SOA server and re-start them after the SOA server is fully initialised after a startup. This can be scripted using WLST, see e.g. http://docs.oracle.com/cd/E15586_01/web.1111/e13813/custom_soa.htm#CIHJIDEA . The advantage of this approach would be to avoid exceptions due to disabled AQs that you would see otherwise in the SOA logs. Furthermore, I would prefer to deal with this on the application server level rather than in the database.
But what if the server crashes and is required to be restarted manually.
- Will it be able to Shut down the composites while server being in the shutdown state/before restart? The documentation says that command can be run offiline but not sure if it will actually shut the composite state failing which composites will start in random order.
- As the development progresses, more and more composite names will get appended to the script to manage them. Would it be good idea then considering the maintenance of the startWeblogic script with a boundary between DBAs who start the servers and Developers who develop the composites ?
Valid concerns. I am pretty sure the WLST script would not work offlne.
In the case of a crash I would assume there is one or several other nodes in the same cluster continuing the business. In a non-clustered environment it would be indeed the case that the composite couldn't be stopped ahead of the server start. Disabling the queue would still work in that (corner) case.
On the operational aspect I am not sure this would be a problem. The development team would have to share such operational details along with their code anyway, but that does not necessarily mean that they take ownership of any infrastructure start/stop scripts.