Tech Mastery: Deep Dives into AEM, Cloud Technologies, AI Innovations, and Advanced Marketing Strate

Welcome to Tech Mastery, your expert source for insights into technology and digital strategy. Explore topics like Adobe Experience Manager, AWS, Azure, generative AI, and advanced marketing strategies. Delve into MACH architecture, Jamstack, modern software practices, DevOps, and SEO. Our blog is ideal for tech professionals and enthusiasts eager to stay ahead in digital innovations, from Content Management to Digital Asset Management and beyond.

Wednesday, September 26, 2012

Overriding or Forcing Local Optimization in Oracle SOA Suite

Overriding or Forcing Local Optimization in Oracle SOA Suite:

Two configuration properties are provided for either overriding or forcing local optimization.

By default, Oracle SOA Suite prefers local optimization. However, you can override this behavior with the oracle.webservices.local.optimization binding property in the composite.xml file. When this property is set to false, local optimization is not performed and cross-composite calls are performed through SOAP and HTTP.

You can override the oracle.webservices.local.optimization property and force optimization to be performed by setting the oracle.soa.local.optimization.force property to true. Use this property in the following scenarios:

The server configuration is sufficiently complicated (for example, there are fire wall or proxy settings in an intranet), which may cause the co-location checks to not deliver the correct result.
You clearly understand the semantics of local optimization, the system setup qualifies for local optimization, and local optimization is absolutely preferred.

If oracle.webservices.local.optimization is set to false and oracle.soa.local.optimization.force is set to false, local optimization is not performed.

The oracle.soa.local.optimization.force property has a default value of false. When this property is set to true, Oracle SOA Suite skips the condition checks.

Another important note about this property is that Oracle SOA Suite always honors the setting of this property (if policy checks allow the optimization). However, if local invocation fails due to non application faults or exceptions (that is, runtime errors mostly related to the direct Java invocation), the value of this setting is ignored for subsequent invocations on the configured endpoint and for all the valid endpoint addresses configured on the endpoint.

To enable the oracle.soa.local.optimization.force property:

Add oracle.soa.local.optimization.force as a binding component level property in the reference section of the composite being invoked. For example, if composite comp_comp2 invokes comp_comp1, then define this property in the reference section of the composite.xml file of comp_comp2.

Configuring Local Optimization in Oracle SOA Suite

Configuring Local Optimization in Oracle SOA Suite:

Local optimization is the process of one SOA composite application invoking another SOA composite application through direct Java invocations in an environment in which both composites are on the same SOA server (JVM).

Direct Java invocations are generally more efficient than SOAP over HTTP calls. Therefore, whenever the conditions are met for direct Java invocations, Oracle SOA Suite optimizes the service calls for the co-located composites.

In 10.1.x releases, we manually configured SOAP optimization with the optSoapShortcut property. For release 11g, SOAP optimization is automatically configured.

Condition Checks for Using Local Optimization:

Oracle SOA Suite performs the following condition checks to determine if local optimization is possible.

It must be a composite-to-composite invocation. This is the most fundamental criteria that makes the direct Java calls possible when both the client and target services are implemented based on the same SOA Infrastructure (that is, the same SOA server).
The composite implementing the reference (target) service must be active. This condition requires the target composite to be up and running, which in turn ensures that the reference service is available.
The client and target composites must be co-located on the same server. This is an obvious requirement for direct Java invocations. It is also a critical step in which Oracle SOA Suite compares the server (on which the client composite is deployed) host configuration with the host and port values specified in the reference (target) service endpoint URI. If the host and port values match, it can be concluded that the client and target composites are located on the same server.
However, the comparison is not necessarily straightforward given that working with both standalone and clustered server setups and potential load balancer configurations is necessary. Therefore, here are the step-by-step condition checks that determine the correct server configuration on all platforms:

Checks the Server URL configuration property value on the SOA Infrastructure Common Properties in em console.

Weblogic Monitoring Dashboard to monitor the resources

Monitoring dashboard is the new feature of latest weblogic server to view diagnostic data without doing additional setup.

This is the extension of the WLDF framework. The Monitoring Dashboard provides views and tools for graphically presenting diagnostic data about servers and applications running on them. The underlying functionality for generating, retrieving, and persisting diagnostic data is provided by the WebLogic Diagnostics Framework. The Monitoring Dashboard provides additional tools for presenting that data in charts and graphs.

The Monitoring dashboard can be launched from the home page of the Web logic administration console or pointing to the direct URL.

Direct URL to access the Monitoring Dashboard - http://<Server Host>:<Server Port>/console/dashboard

Weblogic Server Deployment Staging Configuration

Weblogic Server Deployment Staging Configuration:

We can deploy, redeploy, undeploy, and distribute applications using Weblogic server Administration Console, ANT script or through WLST script.

We can deploy an application as a single archive EAR file or as an exploded archive directory.

Before deploying the application the following server level configuration should be done based on our requirement.

Staging Mode:

The mode that specifies whether an application's files are copied from a source on the Administration Server to the Managed Server's staging area during application preparation.

Nostage mode:

The Administration Server does not copy the deployment unit files to the target servers. The deployment units are deployed directly from the source. This mode is useful when deploying very large deployments to multiple targets. This is the default staging mode for the Administration Server.

Stage mode:

The Administration Server copies the deployment unit files to the staging directories of target servers and they are deployed using the local copy. This mode is useful when deploying small size applications. This is the default staging mode for Managed Servers.

External mode:

In this mode you manually copy the deployment units to the staging directories and then deploy.

Staging Directory Name:

The directory path on the Managed Server where all staged (prepared) applications are placed.

Upload Directory Name:

The directory path on the Administration Server where all uploaded applications are placed.

Configure Deployment Staging:

Log in to Weblogic server Admin console and click on Servers
Click on particular Server then Click on Deployment
Configure the deployment staging accordingly.

Changing Default JPA Provider in WebLogic Server

Changing Default JPA Provider in WebLogic Server :

WebLogic Server has been providing both Kodo and TopLink as JPA providers since WLS 10.3.1.

Unless an explicit <provider>...</provider> is specified in the persistence.xml file of a deployed application, WLS will use Kodo by default.

With the release of WLS 10.3.3, we have now provided a way to change the default JPA provider at the domain level, allowing you to switch between Kodo or TopLink as the default persistent provider that weblogic server will use.

The default JPA provider setting is exposed via a new MBean: JPAMBean on the DomainMBean, and persists the configuration into the config.xml file.

Steps to Change the Default provider:

Login to weblogic server console
Click on the Domain and click on JPA
Change the Default JPA Provider to TopLink and click on Save

Oracle TopLink is the default persistence provider in WebLogic Server 12c and later but you can change to Kodo if required.

Modifying the DVM’s and Business Rules using SOA Composer

Oracle SOA Suite Composer is a J2EE application deployed into the weblogic server that help us to edit the DVM’s and the Business Rules after the deployment to the Oracle SOA Suite server during the runtime.

The SOA Composer application can be accessed using the following URL

http://<SOA Server Host>:<SOA Server port>/soa/composer/

To modify the DVM’s or the Business Rules the weblogic user must have the SOADesigner role.

When using Oracle SOA Composer, you can save your customizations in a sandbox environment without applying them to a running instance and later return to the sandbox to make additional customizations. These customizations are only applied to the running instance when you click Commit.

Modify DVM:

Login to SOA Composer
Click on open and then click on Open DVM, this will list all the DVM’s deployed to MDS

java.lang.ClassCastException: weblogic.jms.common.DurableSubscription cannot be cast to weblogic.jms.backend.BEConsumerCommon

I was receiving the following exception in my local Oracle SOA Suite environment 11.1.1.6.0.

java.lang.ClassCastException: weblogic.jms.common.DurableSubscription cannot be cast to weblogic.jms.backend.BEConsumerCommon

at weblogic.jms.backend.BackEnd.dump(BackEnd.java:2880)

at weblogic.jms.JMSService.dump(JMSService.java:1169)

at weblogic.jms.common.JMSDiagnosticImageSource.createDiagnosticImage(JMSDiagnosticImageSource.java:43)

at weblogic.diagnostics.image.ImageSourceWork.run(ImageSourceWork.java:111)

at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)

Truncated. see log file for complete stacktrace

After analysis found that this is a known issue related to weblogic server versions 10.3.4 and 10.3.5.

Solution:

Download and apply the patch 10023173 from Metalink.

Saturday, September 22, 2012

Cluster Constraint for the deployment in weblogic server

Cluster constraint specifies that deployments targeted to a weblogic cluster succeed only if all servers in the cluster are running.

When this option is enabled, WebLogic Server enforces a strict two-phase deployment policy for all Managed Servers in a domain—ensuring that application deployment to a cluster succeeds only if all Managed Servers in the cluster are reachable and can deploy the application. If any server instance in the cluster is unreachable, the application is not deployed to any of the Managed Servers.

If you do not enable this option, WebLogic Server allows deployment to a partial cluster. When the unreachable Managed Server becomes available, deployment to that server instance will be initiated.

By default, cluster constraints are disabled and deployment is attempted only on the servers that are reachable at the time of deployment from the Administration Server.

To Enable Cluster Constraint:

Login to Weblogic Admin Console
Click on the domain name
Select the Check box against “Enable Cluster Constraint”

Installing the patches to weblogic server using Oracle Smart Update

Installing the patches to weblogic server using Oracle Smart Update:

Oracle Smart Update tool help us to apply and manage the patches for weblogic server.

As of Smart Update 3.3.0, the Get Patches tab has been removed, and you can no longer use Smart Update to download patches, service packs, maintenance packs, or version upgrades. You must first download the appropriate patch or patches directly from My Oracle Support. Once downloaded, you can use Smart Update to apply the patches.

Smart Update 3.3.0 no longer prompts you to register for security updates from Oracle Configuration Management (OCM).

The version can be verified from Help -> About.

This blog will explain the steps to install the patches to a weblogic server using Oracle Smart Update.

Steps to install the patches to a weblogic server using Oracle Smart Update

Download the patch through metalink using the patch id or bug no.
Uncompress patch zip file to $MWHOME/utills/bsu/cache_dir (If the cache_dir folder is not available then create the same)

Launch the Oracle Smart Update Tool (bsu.cmd) from $MWHOME\utils\bsu, this will list all the applied patchs and all those patches that are ready for installation.

CodeCache is full. Compiler has been disabled - Oracle SOA Suite 11g

CodeCache is full. Compiler has been disabled - Oracle SOA Suite 11g:

Frequently we used to see the below message in our log file.

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=

The code cache is a memory area separate from the JVM heap that is used for compilation and storage of native code.This is where the JIT compiled methods are kept.

The JIT compilier will be disabled when the code cache is full. Once the JIT compiler is switched off due to the Code Cache being full, it does not switch back on.

This will affect the performance of the server in high extend.

We can try to increase the default code cache size to resolve this issue.

Steps to increase the code cache size(we have increased to 64m)

Login into Admin Server node
Open $DOMAIN_HOME/bin/setSOADomainEnv.sh file
Edit the "DEFAULT_MEM_ARGS" to add the following parameters at the end of line before double quotes: -XX:InitialCodeCacheSize=64m -XX:ReservedCodeCacheSize=64m
Login into admin console and go to all the servers server start up properties tab and edit the section to add the following parameters at the end of the line -XX:InitialCodeCacheSize=64m -XX:ReservedCodeCacheSize=64m

Restart all servers (Admin and Managed)

Monday, September 17, 2012

Import/Publish the services from Oracle Service Bus to Service Registry

Import/Publish the services from Oracle Service Bus to Service Registry:

The OSB services can be published to OSR; the service consumer can consume the services from the OSR also OSB can import and consume the services from OSR.

This blog provides the step to configure and import/publish the services to OSR.

Configure the OSR:

Login to OSB console
Select System Administration and click on UDDI Registries and click Add Registry

Enter the Oracle Service Registry details as shown below and click on save

Storing the Cross reference data to a custom table - Oracle SOA Suite:

Cross references enable you to dynamically map values for equivalent entities created in different applications. Cross references are stored in the form of tables.

Oracle SOA Suite 11g provides the new feature to store the cross reference data to a custom table instead of storing to a standard XREF_DATA table, this feature enable as to manage the data properly.

Different tables can be created based on the data like order data can be stored in XREF_ORDER table and account data can be stored in the XREF_ACCOUNT. This will improve the performance of populating and looking up the data whenever the volume of the data is more.

Right-click the project and select New.

Select SOA Tier from the Categories section, and then select Transformations.

Select Cross Reference (XREF) from the Items section.

The screen is different in Oracle SOA Suite 12c to create the custom XREF.

Click OK.

In the File Name field, specify the name of the cross reference file.

In the End System fields, enter the end system names.

Click OK.

Identifying the weblogic server version installed

How to identify the weblogic server version installed

1. cd %DOMAIN_HOME%/bin
2. Execute setDomainEnv.cmd
3.Execute java weblogic.version -verbose

The weblogic server version is 10.3.5.0

Pages