BPEL process deployment

Question

What is required to deploy a BPEL process on another machine (or oracle home)?
Here is my current list in order, let me know if there is anything additional or if there are any short cuts/wizards to make doing this easier. Also if you don’t need to be able to recompile the program, are any of the steps (b – e) not needed / changed if you just copy over and manually deploy the jar file?
a) Copy the workspace folder to the new machine/oracle home and then add it to the application navigator.
b) Re-add or copy entries in the email/JMS/FTP adapter config files.
c) Re-add task users. (Can there entries be copied from one file to the other?)
d) Make sure all referenced local folders exist and are accessible.
e) Make sure all referenced BPEL processes are deployed.
This includes the User task services, they seem to be deployed when a user task is added but not when a BPEL process they include is deployed in a new environment.
f) Compile/deploy the process.
Thanks,
Craig

Answer 1

Hi Craig -
Your list of steps will certainly work. However, as you suggest, you don't need to recompile the BPEL process on the new machine. You can just copy the jar (what we call the "BPEL suitcase" that is created when you compile the BPEL process. For more information on this, and the different mechanisms for deploying BPEL suitcases, see the technote at:
http://www.oracle.com/technology/products/ias/bpel/htdocs/orabpel_technotes.tn002.html
Regarding the user task services, these should just "do the right thing". If you are finding that you deploy a process to a new domain that uses the task service and the task service itself is not automatically deployed by the server, send us the steps to reproduce - this would be a bug (though your workaround of manually deploying the task service would be fine in the meantime).
Beyond that, there are a few best practices that we have which may eliminate steps (c) and (d) in your list (task users and referenced local folders). We would recommend avoiding local folder references that go outside of the BPEL suitcase when possible and using URL references for things like XSDs. This way you can have a central repository that is available from all the pertinent servers.
Alternatively, you can include the necessary files with your process in a higher level directory and have an Ant build.xml which copies them to the appropriate locations. We try to do this with our samples, so that there is a single directory (typically called xxxDemo, e.g. LoanFlowDemo) that has a master build.xml that builds all the sub-directories (which typically include a BPEL process, xxxFlow, a UI, dependent services, etc). See the samples in the orabpel\samples\demos directory for several examples of this approach that you may be able to leverage.
Finally, regarding task users, I'm not sure if there is a simple mechanism for copying them over with our default developer install authentication. I'll check on this however - the question makes sense and we should both make this possible and ship an example where the appropriate users are created as part of the umbrella build.xml for a project. I suspect this will require a simple SQL script, but again I'll check. However, in many cases, again the best practice would be to use an LDAP or similar, globally accessible directory. Then any deployments which have access to the directory service would not require this additional step.
Let me know if any of this doesn't make sense.
Dave
David Shaffer
Dir Product Mgmt, Oracle BPEL Process Mgr
[email protected]
W: 650.506.1729
http://otn.oracle.com/bpel