Change the log files location of a WebLogic Domain

In a default WebLogic Domain you can have various WebLogic logfiles located at different locations. For administrators it can be hard to find them all and these log files can have and grow to a large file size which can lead to a full file system. In this blogpost we will move these log files to one location.

For example when we take a look at the logs folder of the AdminServer you will see off course the WebLogic server log called AdminServer.log , the domain log in this case base_domain.log, access.log for the HTTP request logging and the FMW log called AdminServer-diagnostic.log.

At a managed server logs folder location you can also see the server1.out and server1.out00001 log files. These files are created by the NodeManager when we start the Managed servers from the WebLogic Console.

 First let's move the Domain log.

Then change the General log file for all the WebLogic Servers.

Also do this for the HTTP access.log and rename the logfile to servername_access.log else it will conflict with the other servers.

To control the NodeManager standard and error output of the Managed Servers you need set the following weblogic.Stdout weblogic.Stderr parameters. Add these parameters to the argument field of all the managed server which will be started by the NodeManager.

When you enable at least the JRF or the Enterprise Manager option on your domain you need to change the location of the FMW log files. Go the Enterprise Manager Application and select all the Managed Servers.

Click on odl-handler and press the Edit Configuration.

Change the path of the log file.

Now you have one location which contains all the log files.

Publish to EDN from java & OSB with JMS

My previous blogpost was about how to configure the SOA Suite EDN for JMS ( EDN-JMS ) instead of AQ (EDN-DB) and in this blogpost I will show you how you can publish events from Java and OSB.

Before we start you should know that we can only make Remote Event Connections because you are running the Java or OSB process in a different JVM then the SOA Suite. And only asynchronous subscriptions will be supported for remote event connections.

First let's create a Java Client which publish the events directly to the SOA Suite Server. I will use the jars of the SOA Suite. This is not necessary. You can just publish a JMS text message and set some JMS Header properties (MessageType and SideCar )

Make a new JDeveloper  project which contains the following libraries.

Here is my test class.
And this will produce the following event on the EDN Queue.

The second part of this blogpost is how to do this in OSB.
Before we can work on the Proxy or Business Service we need to create a Foreign JNDI Provider on the WebLogic Service. ( You can also use a JNDI Provider of the OSB Configuration project )

Provide the SOA Server details.

Provide the local and remote EDN-JMS JNDI Link names. The Remote JNDI Names are fixed but you can change your  local ones.

Restart the OSB Server and open OEPE or the SBConsole.

Create a new Business Service and choose for Messaging Service as Service Type.

Event is an One Way Operation so only need to set the Request Message Type to text.

Use the Local JNDI names of the Foreign JNDI Provider in the Endpoint URI

 Select Text as Message Type.

Create a Proxy Service which call this Business Service, where we will replace the Body contents with the event data and set some JMS Headers in the Transport Header.

 Replace the body contents in a Replace Action.

My test event, the values of Id and ecid element contains unique UUID values.

And the last part is to set the Messagetype and SideCar JMS Headers

MessageType is always Remote
SideCar in my case

<business-event-sidecar xmlns:ns="http://schemas.oracle.com/events/edl/EmployeeEventEDL"
                        xmlns="http://oracle.com/fabric/sideCar">
<name xmlns="http://oracle.com/fabric/businessEvent">ns:EmployeeEvent-sidecar</name>
</business-event-sidecar>

You can test the Proxy Service in the SBConsole.

Configure and test JMS based EDN in SOA Suite 11g

Beside the default AQ implementation it is also possible to use a JMS Queue for EDN. When you use the JMS implementation in SOA Suite 11g instead of AQ, it can be easier to publish an event from a Java Web application, WebLogic SAF, MDB or from OSB. In this blogpost I will show you how to configure EDN-JMS and how to publish an Event to this JMS Queue.

When you take a look at the SOAJMSModule located at the JMSModules of WebLogic you can see that the module already contains an EDN Queue and an EDN ConnectionFactory.

So you only need to configure SOA Suite so it uses this Queue and Connection Factory. To do so open the enterprise manager application | SOA | soa-infra and open the Common Properties Menu item of the SOA-Infrastructure menu. Click on More SOA-Infra Advanced Configuration Properties

This will open the System MBean Browser. In this we can change the EdnJmsMode and set this to true.

Restart the SOA Server and take a look at the monitoring of the EDN Queue. Here you must see there are some Queue Consumers

Second part of this blog is to publish a event. For this I made a simple Employee Id XSD which can be published.

Create a SOA Project and add a Mediator with a One Way Operation which uses this XSD. Also expose this Mediator so you can invoke this operation from the Enterprise Manager.

Add a routing rule and choose for an Event.

 Define an Employee Event.

Add a transformation and map the source and destination elements

Your composite will look like this.  Deploy the composite to the SOA Server.

To see the event you need to pause the consumption of the EDNQueue.

Open the Enterprise Manager and test the service of the EDN composite.

Go back to the EDNQueue and look at the JMS Message. It contains some SOA instance tracing elements and has a MessageType JMS Header which defines the EDN mode.

In the following documentation you can read about, how to create a Foreign JNDI provider on your ADF server so you can publish JMS EDN events from an ADF Client.

38.3.6 How to Configure JMS-based EDN Implementations

In one of the future blogposts I will publish an JMS event from a Java Client.