Cloud Control agent does not deal well with redeployments

Cloud Control Agent shows SCA as down after redeployment




In a lot of environments the development process calls for a daily rebuild of the system. This is typically followed by a (re)deployment of the SCA’s to the Fusion Middleware environment.

In one of my customers environments I had to deal with the issue that each morning the SOA SCA’s were depicted in the Cloud Control as down. A quick check on the server showed them up and running. The same happened in the Enterprise Manager of the server. So the redeployment worked as it should.

So why were the SCA’s noted as down in the Cloud Control when the EM showed them as up? This has to do with the way the agent of the Cloud Control works. The interactive way is described in the following manual: http://docs.oracle.com/cd/E24628_01/install.121/e24215/fmw_discovery.htm

Now when an agent has found an SCA it does not automatically update the lifecycle status of this deployment. So a redeployment does add a new label to a SCA in a partition. The agent seems to be unaware of such a change in the partition and clings to its formerly known label.

Obviously it is disturbing when you look into your Cloud Control dashboard and you find that a (large) number of targets are down.

The Admin Guide shows how to manually update the collection.

In http://docs.oracle.com/cd/E24628_01/install.121/e24215/fmw_discovery.htm#BABCEADC the process to look for new or modified targets is described. That certainly works if you have only a small environment (say one or two SOA Suite installations) with a low-frequency of redeployments. If you redeploy each night you will need a better approach.

The problem with the automation of this approach is that it is very well hidden (and to my knowledge) not documented.

What you need to do is to go to the domain that contains your deployments. In that summary screen you will see the status (below a screenshot after a manual refresh).

Look at the Date/Timestamp on the page (red circle). If you click on it the following pop-up box will show:

When you check the box next to “Enable Automatic Refresh” you will end with a job that will be editable in the job list. You cannot create such a job in the job section, but you can edit its frequency. The best frequency is to do this right after the nightly deployment run.

SOA Suite partitioning

For a customer I am busy to develop a SOA Suite purging strategy. As we expect the system to have a high number of instances we will have to keep the dehydration store and the MDS clean. The last is also essential as the end customer is under some budget constraints, which leads to the fact that the database (and especially the size of the disks) is nothing that will be allowed to grow limitless.

Now - one of the important features of the database when it comes to space management is partitioning. Partitioning a table gives you more management capabilities and tools to keep your DB size manageble.

There are a number of pointers in the documentation that describe how the database partinioning can be used for the SOA Suite - with one essential part missing: how to set it up.
There is a remark that the creation of partitions is a task for a skilled DBA (true) and a second remark that states that the admin guide will not describe it.

So when you want to use partitioning for your SOA Suite MDS you are on your own.
The RCU won't help you, the admin guide is vague and Google seems to point to SOA Suite partinioning in a different sense (the old BPEL domains).

There is only one thing that can help: an Oracle ACE willing to make it work, document it and spread the word.
So stay tuned as I will post my findings here in the next couple of days/weeks.

How Oracle SOA saved my life

OK - I exaggerated a little bit in the title - but as you may have noticed - it is VERY cold in central Europe. Now this guy here loves the sun. I admit I love the SUN products as well, but normally I refer to the big yellow thing in the sky.

Leaving the Netherlands for a long weekend with my wife to travel to Malaga is nice. But to feel the Spanish winter sun with 16 C (+ that is) instead of the Dutch version of it (-10) gave me the feeling that coming to Malaga for the SOA Community Forum is a kind of a life saver. So yes - I combined business with pleasure, but sometimes you just have to.

In addition to that - staying abreast of things that go on in the community, in the SOA Suite arena in general and meeting a couple of old friends (and hopefully making some new ones along the line) is a thing that can be compared to a life saver. Although in a project an error does not automatically mean that blood flows through the streets, having a good knowledge of the products you work with is very helpful.

So I hope that you will envy me to type this in the afternoon sun, enjoying tapas and meet some folks tonight in Malaga, instead of freezing, eating snert (look it up on Wikipedia).
Come to an Oracle Fusion Middleware Community as well - it might save your life ;-)

Use RDA or Enterprise Manager for Governance

Within my current project I ended up in an interesting discussion. As part of the governance or more specifically some government regulations for the systems security we needed a description of the system components.

Obviously there are several layers for this topic, but in order to have a complete view of the system a list of installed system components and also of the systems configuration was desired.

Well, as you can guess, there was no tangible description of the current configuration, and there was also only a sketchy overview of the Oracle components which were used to build the system.

So, the first idea was to ask the various departments which were involved in the setup and configuration of the system to use a variety of tools and approaches to deliver the information.
I offered the idea to use "the one ring to rule them all" approach. Oracle offers two tools that provide an overview of the used components, their configuration and even of platform settings.

One tool would be either the local Enterprise Manager or the central Grid Control (Cloud Control if you are up to date). The problem is that from the Enterprise Manager perspective, each of the layers (host, OS, storage, Oracle components, configuration) would need its own report. So a number of reports would need to be executed.

So my thought turned to the Remote Diagnostic Assistant. The RDA is a tool that is used by Oracle Support to gather information of the system setup, OS settings, and the like.

So I downloaded RDA for one of the machines, unpacked it, configured it and executed it.
Within minutes you'll have the output of a large number of Perl scripts.

The good thing is that the presentation is provided in a human readable format (HTML) so that a support analyst or the DBA can have a glance at the data.
But even more interesting is the fact that each HTML page is also available as a text file, with a nice structure.

So with the intention of building a prototype, I used some AWK scripts to get the data out of the text files, and used it as input for the data pump.
Create some tables in a new tablespace, get the data into it and you have a description of your technical components for your governance.

Next step would be to add the date of the execution, and you could easily figure out if changes had happened in the last period and add them to your governance.

So again a nice use of things you already have in your environment which can be put to good use for slightly different purposes as they were intended in the first place.