These Virtual Machines can be quite demanding for resources on your PC or laptop. Fortunately there are ways to speed up VirtualBox appliances. Besides increasing the allocated CPU power and RAM there are a few less expected things you can do:
Create fixed size disks – A preallocated disk will have less fragmentation. Adding of files to the virtual disk will be faster (spaces is already reserved). The downside is that a fixed-size disk uses more space on your hard disk.
Exclude the Virtual Machine directory from the virus scanner – Scanning there from the host isn’t very useful either. So add this directory to the exclusion list.
Put the VirtualBox files on non-system disk – Put the VirtualBox files on a non-system disk. The virtual disk and your hosts’s OS won’t be competing to read from or write to these same disk.
Make shure the Intel VT-x and AMD-V setting is ON – These are processor extensions that improve virtualization performance.
To create Oracle BPM processess with JDeveloper you need to install the BPM Studio extension. This is similar to installing the SOA Suite extension.
Ensure that the desired version of JDeveloper is installed. You can download JDeveloper here. Should you be unsure on how to install JDeveloper check the SOA Suite quick start guide to guide you.
Install JDeveloper BPM Studio extension
Install JDeveloper in a seperate Middleware Home. When starting JDeveloper choose the “Default” role. To enable JDeveloper to perform development for the SOA Suite and develop and deploy SCA composites you have to install an extension called SOA Composite Editor. When you want to develop BPM processess you need to install BPM Studio extension following these steps:
Select Help > Check for Updates
Click Next
Select Oracle Fusion Middleware Products and Official Oracle Extensions and Updates and click Next
Select Oracle SOA Composite Editor and Oracle BPM Studio 11g and click Next
Although there can be a lot of debate on what is Architecture in the world of IT and on who is an architect and who isn’t, I think it is clear that it is not exactly Brain Surgery. And i think that is actually a good thing. Although the implementation of a (Service Oriented) Architecture is in most cases bound to hit vital parts of an organization it isn’t …
And even though there can be just as many parameters in the larger equations, architecture isn’t exactly rocket science either…
There is a growing number of Twitter Apps that trick you into giving them access to your account and so enabling them to send spam on your behalf. Should you (like me at least once) fall for this trap, here is an easy way to prevent further damage. Use the following url: http://twitter.com/settings/connections or click the links that are highlighted in the screen shot on the right to manage your Twitter connections.
After that you just click Revoke Access below the Application that is using your account to spam others. An example is depicted in the screen shot below (for a non spamming App):
While using the AIAMigrationUtility the following error occurs:
1
2
3
4
5
6
7
8
9
[exec] [upgrade] Jul 26, 2010 3:02:04 PM oracle.viewgen.ViewGenerator main
[exec] [upgrade] SEVERE: Upgrade failed. Check the logs for any exceptions. Ensure that the WSDL URLs specified in the project are reachable and a valid 10.1.3.x project is used for upgrade. Before re-attempting upgrade, restore the original project code source from the backup directory.
[exec] [upgrade] oracle.j2ee.ws.wsdl.LocalizedWSDLException: WSDLException: faultCode=OTHER_ERROR: Failed to read WSDL from http://serverdomain:8001/orabpel/default/AIAAsyncErrorHandlingBPELProcess/1.0/AIAAsyncErrorHandlingBPELProcess?wsdl:WSDL not found
[exec] [upgrade] at oracle.viewgen.plugin.bpel.BPELPlugin.createComponentType(BPELPlugin.java:172)
[exec] [upgrade] at oracle.viewgen.ViewGenerator.main(ViewGenerator.java:223)
[exec] [upgrade] Caused by: oracle.j2ee.ws.wsdl.LocalizedWSDLException: WSDLException: faultCode=OTHER_ERROR: Failed to read WSDL from http://serverdomain:8001/orabpel/default/AIAAsyncErrorHandlingBPELProcess/1.0/AIAAsyncErrorHandlingBPELProcess?wsdl:WSDL not found
[exec] [upgrade] at oracle.j2ee.ws.wsdl.xml.WSDLReaderImpl.openAsStreamConnection(WSDLReaderImpl.java:541)
[exec] [upgrade] at oracle.j2ee.ws.wsdl.xml.WSDLReaderImpl.readDocument(WSDLReaderImpl.java:427)
[exec] [upgrade] at oracle.j2ee.ws.wsdl.xml.WSDLReaderImpl.readWSDL(WSDLReaderImpl.java:366)
There is a regular expression in the replaceAIAAsyncURL target that doesn’t handle the versioned url. You can either replace it so it allows for version numbering:
In today’s post you can find out why you need a changelog, and what activity to add to your upgrade roadmap.
After a recent upgrade of SOA Suite to a more recent patch level, we saw errors that some of us vaguely remembered. They were traced back to transaction timeouts in the BPEL Server. Searching Metalink, OTN, and of course Google we found out we had to change the transaction-timeout and min-instances in the orion-ejb-jar.xml. More detailed information on these settings can be found on in the SOA Suite best practises. However they are not in the spotlight of this post. So let’s go back to the main story.
At that time it seemed strange that the suggested values in the documentation, and as mentioned in blogposts, conformed with the ones we thought set in production.
Need for a changelog
Fortunately we have a changelog. We checked it, and indeed the values should correspond. We set these during a previous tuning effort. Time to check the actual orion-ejb-jar.xml in the production environment. Oops! During the SOA Suite upgrade our fine tuned orion-ejb-jar.xml was overwritten with one with default values
Recommendations
What can you learn from our experience:
Maintain a changelog – also for configuration settings;
Include a post upgrade action in your plan to check whether all tuning and other configuration settings are still at the appropriate values;
Oh, and by the way, keep your test environment in sync with production (including all configuration settings)! So all this can be well planned and tested before the actual go live.
There are two places to determine the version of the SOA Suite you are running:
The SOA Suite welcome screen
Oracle patch utility
SOA Suite welcome screen
SOA Suite version
This is the page that is displayed when you navigate to: http://your-SOA-Suite-host:its-port/
It contains a part that looks like this image:
Oracle patch utility
For a more detailed look we turn to the Oracle patch utility OPatch. The OPatch utility is located in the /OPatch directory. It is run with options and command-line arguments. A User’s guide can be found here.
The lsinventory command reports what has been installed on the system for a particular Oracle home directory, or for all installations. A result for using this command is shown in the screenshot:
opatch lsinventory
One can use this info in combination with metalink.
Overview of SOA Suite versions
An overview of all release downloads can be found on OTN.