Showing posts with label SOA 11g. Show all posts
Showing posts with label SOA 11g. Show all posts

Monday, 17 March 2014

Applying Patch 16707698: TASK LISTING FILTER NOT WORKING AS EXPECTED on SOA 11.1.1.7.2

Applying Patch 16707698: TASK LISTING FILTER NOT WORKING AS EXPECTED on SOA 11.1.1.7.2

- Prerequisite Patches

17584181 SOA BUNDLE PATCH 11.1.1.7.2

- Download patch 16707698
- Apply patch on SOA Home

bash-3.2$ opatch apply
Oracle Interim Patch Installer version 11.1.0.9.9
Copyright (c) 2012, Oracle Corporation.  All rights reserved.

Oracle Home       : $MW_HOME/product/111/soa_111
Central Inventory : $MW_HOME/oraInventory
   from           : $MW_HOME/product/111/soa_111/oraInst.loc
OPatch version    : 11.1.0.9.9

OUI version       : 11.1.0.9.0

OPatch detects the Middleware Home as "$MW_HOME/product/111"
Applying interim patch '16707698' to OH '$MW_HOME/product/111/soa_111'

Verifying environment and performing prerequisite checks...
All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.

(Oracle Home = '$MW_HOME/product/111/soa_111')

Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...


Patching component oracle.integration.bpm, 11.1.1.7.0...
Patching component oracle.integration.soainfra, 11.1.1.7.0...

Verifying the update...


Patch 16707698 successfully applied

Related:

java.lang.NullPointerException ADF_FACES-60097: For more information, please see the server's error log for an entry beginning with: ADF_FACES-60096:Server Exception during PPR, #10

Applying Patch 17584181 SOA BUNDLE PATCH 11.1.1.7.2

Applying Patch 17584181 SOA BUNDLE PATCH 11.1.1.7.2


Pre-Patch Instructions

- Review and download the latest version of OPatch 11.1.x via Bug 6880880

- Ensure access to valid OUI Inventory by running opatch lsinventory

- Validate the executables in system PATH like 'which opatch', 'which unzip'


- You MUST apply this patch to both SOA Home $MW_HOME/Oracle_SOA1 and Oracle Common Home $MW_HOME/oracle_common without fail.

Applying Patch 17584181

1) Apply patch 17584181 on oracle_common

bash-3.2$ export ORACLE_HOME=$MW_HOME/product/111/oracle_common

bash-3.2$ opatch apply

Oracle Interim Patch Installer version 11.1.0.9.9

Copyright (c) 2012, Oracle Corporation.  All rights reserved.

Oracle Home       : $MW_HOME/product/111/oracle_common
Central Inventory : $MW_HOME/oraInventory

   from           : $MW_HOME/product/111/oracle_common/oraInst.loc

OPatch version    : 11.1.0.9.9
OUI version       : 11.1.0.9.0

OPatch detects the Middleware Home as "$MW_HOME/product/111"
Applying interim patch '17584181' to OH '$MW_HOME/product/111/oracle_common'
Verifying environment and performing prerequisite checks...

Patch 17584181: Optional component(s) missing : [ oracle.integration.bpm, 11.1.1.7.0 ] , [ 
oracle.integration.soainfra, 11.1.1.7.0 ] , [ oracle.rules, 11.1.1.7.0 ] , [ 
oracle.soa.common.adapters, 11.1.1.7.0 ] , [ oracle.bpm.processspaces, 11.1.1.7.0 ] , [ 
oracle.rcu.soainfra, 11.1.1.7.0 ]

Interim patch 17584181 is a superset of the patch(es) [  17014142 ] in the Oracle Home

OPatch will roll back the subset patches and apply the given patch.
All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.

(Oracle Home = '$MW_HOME/product/111/oracle_common')

Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...

Rolling back interim patch '17014142' from OH '$MW_HOME/product/111/oracle_common'
Patching component oracle.bpm.mgmt, 11.1.1.7.0...
RollbackSession removing interim patch '17014142' from inventory
OPatch back to application of the patch '17584181' after auto-rollback.

Patching component oracle.bpm.mgmt, 11.1.1.7.0...

Patching component oracle.soa.mgmt, 11.1.1.7.0...

Verifying the update...

Patch 17584181 successfully applied

2)  Apply patch 17584181 on SOA Home

bash-3.2$ opatch apply

Oracle Interim Patch Installer version 11.1.0.9.9
Copyright (c) 2012, Oracle Corporation.  All rights reserved.

Oracle Home       : $MW_HOME/product/111/soa_111
Central Inventory : $MW_HOME/oraInventory

  from           : $MW_HOME/product/111/soa_111/oraInst.loc
OPatch version    : 11.1.0.9.9
OUI version       : 11.1.0.9.0

OPatch detects the Middleware Home as "$MW_HOME/product/111"

Applying interim patch '17584181' to OH '$MW_HOME/product/111/soa_111'

Verifying environment and performing prerequisite checks...

Patch 17584181: Optional component(s) missing : [ oracle.bpm.mgmt, 11.1.1.7.0 ] , [ 
oracle.soa.mgmt, 11.1.1.7.0 ] , [ oracle.bpm.processspaces, 11.1.1.7.0 ] , [ oracle.rcu.soainfra, 
11.1.1.7.0 ]

Interim patch 17584181 is a superset of the patch(es) [  16886343 17014142 ] in the Oracle Home

OPatch will roll back the subset patches and apply the given patch.
All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '$MW_HOME/product/111/soa_111')

Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files...

Rolling back interim patch '16886343' from OH '$MW_HOME/product/111/soa_111'
Patching component oracle.integration.bpm, 11.1.1.7.0...
RollbackSession removing interim patch '16886343' from inventory
Rolling back interim patch '17014142' from OH '$MW_HOME/product/111/soa_111'

Patching component oracle.integration.bpm, 11.1.1.7.0...
Patching component oracle.integration.soainfra, 11.1.1.7.0...
Patching component oracle.rules, 11.1.1.7.0...
Patching component oracle.soa.common.adapters, 11.1.1.7.0...

RollbackSession removing interim patch '17014142' from inventory

OPatch back to application of the patch '17584181' after auto-rollback

Patching component oracle.integration.bpm, 11.1.1.7.0...
Patching component oracle.integration.soainfra, 11.1.1.7.0...
Patching component oracle.rules, 11.1.1.7.0...
Patching component oracle.soa.common.adapters, 11.1.1.7.0...

Verifying the update...

Patch 17584181 successfully applied

If any issues after applying patch and rollback is required, run below command:

$ opatch rollback -id 17584181 and restart the services

Related posts:

Applying Patch 20900797: SOA Bundle Patch 11.1.1.7.8

Applying Patch 20423535: SOA Bundle Patch 11.1.1.7.7

Applying Patch 19953598: SOA Bundle Patch 11.1.1.7.6

Applying Patch 19190139 SOA BUNDLE PATCH 11.1.1.7.5

Applying Patch 18609527 SOA BUNDLE PATCH 11.1.1.7.4

Applying Patch 18072286 SOA BUNDLE PATCH 11.1.1.7.3

FMW 11.1.1.6.0 - Applying Patch 16702086: SOA BUNDLE PATCH 11.1.1.6.7

Applying Patch 16707698: TASK LISTING FILTER NOT WORKING AS EXPECTED on SOA 11.1.1.7.2

java.lang.NullPointerException ADF_FACES-60097: For more information, please see the server's error log for an entry beginning with: ADF_FACES-60096:Server Exception during PPR, #10

Sunday, 5 January 2014

Comparing oracle.net.CONNECT_TIMEOUT and JDBC statement-timeout values for SOA 11g default datasources.

Comparing oracle.net.CONNECT_TIMEOUT and JDBC statement-timeout values for SOA 11g default datasources.

Default Data Sources that can be checked in Weblogic console:

SOA
SOA Local TX
EDN
EDN Local TX
mds-soa
mds-owsm

Under $DOMAIN_HOME>/config/jdbc

Check the specific configuration files:

mds-soa-jdbc.xml
mds-owsm-jdbc.xml
SOADataSource-jdbc.xml
SOALocalTxDataSource-jdbc.xml
EDNDataSource-jdbc.xml
EDNLocalTxDataSource-jdbc.xml


In each file look for entries like below:

<property>
        <name>oracle.net.CONNECT_TIMEOUT</name>
        <value>10000</value>
</property>

and

<statement-timeout>60</statement-timeout>

It is recommended to set both the properties and that statement-timeout value exceeds that of CONNECT_TIMEOUT. Both the properties can be set in Weblogic Console in Data Source configuration area.

Setting these properties ensures you do not end up with stuck threads in runtime or a hung server requiring restart.

Monday, 16 September 2013

Recovering failed instances / messages in SOA 11g using Enterprise Manager

Recovering failed instances / messages in SOA 11g using Enterprise Manager

Want to recover failed instances in SOA? Below are the high level steps to recover.

- Login to SOA EM console http://virtualhost.example.com/em

- On the left side tree navigation, go to Farm_soa_domain > SOA > soa-infra (WLS_SOA1)

- Right click on soa-infra (WLS_SOA1) and then select Service Engines > BPEL



- In the BPEL Service Home page, you will see tabs - Dashboard, Statistics, Instances, Faults, Deployed components, Recovery.

- Click on Recovery tab

- Select the following from the drop downs.
Type:  Invoke , Duration: Select appropriate duration you need to check, Message State: All

- Select the relevant conversation ID and click on 'Recover' tab. Repeat this for all the conversation IDs that need to be recovered.

Please note you can recover or cancel selected messages marked as Recoverable. If messages are marked as Exhausted you can select them and click Reset to return them to the auto-recovery queue, click Mark Cancelled so that recovery is never attempted on them, or click Recover to attempt to recover them immediately.


Friday, 29 March 2013

AIAReadJMSNotificationProcess [1.0] in unknown state in SOA 11g EM Fusion Middleware Console


AIAReadJMSNotificationProcess [1.0] in unknown state in SOA 11g EM Fusion Middleware Console


Are you seeing AIAReadJMSNotificationProcess [1.0] composites in unknown states in your SOA enterprise manager console?


Errors as below:

<Error> <oracle.integration.platform> <SOA-20020> <Deployment of composite "AIAReadJMSNotificationProcess" failed: Error in getting XML input stream: http://soa.localhost.com:port/soa-infra/services/default/AIAErrorTaskAdministrationProcess/AIAErrorTaskAdministrationProcess.wsdl: Connection reset.>
====> CubeEngine load AIAErrorTaskAdministrationProcess/AIAErrorTaskAdministrationProcess took 476 ms


AIAReadJMSNotificationProcess appears in unknown state on SOA cluster nodes


Composite is in Failed state because it may not have got deployed when soa_server has been started. This may be because you have dependencies between your SOA Composites and AIAReadJMSNotificationProcess that has been deployed before AIAErrorTaskAdministrationProcess it depends on. 

For quick fix:

- restart soa_servers but it may happen again because deployment order of SOA Composites cannot be configured

or 

- redeploy AIAReadJMSNotificationProcess composite


For long term fix, follow:

Doc ID 1151973.1 Boot Order Of The Composites Upon Soa Suite Restart


Doc ID 1369101.1 SOA Server With AIA Unable to Look Up WSDL's At Startup

associated with bug: 12979076 - SOA11G MANAGED SERVER WITH AIA FAILS LOOKING UP WSDL AT STARTUP