How can you timeout invocation of external endpoints from BPEL

SyncMaxWaitTime setting applies to synchronous process invocations when the process has a breakpoint in the middle of the process. If there are no breakpoints, the entire process will be executed by the client thread. If there is a breakpoint then a new thread will be spawned to continue the processing after the break. For more details, follow the link.

In order to explicitly set the timeout for the endpoints invoked from within the BPEL, use the following reference binding properties to configure timeouts while invoking external services.

<reference name="HWService">
 <interface.wsdl interface="writeHW_ptt">
 <binding.ws port="helloWS">
 <property name="oracle.webservices.httpReadTimeout" type="xs:string" many="false">10000</property>
 <property name="oracle.webservices.httpConnTimeout" type="xs:string" many="false">10000</property>
 </binding.ws>
 </reference>
 

The property "oracle.webservices.httpReadTimeout" specifies how long to wait until the target service processes the request and "oracle.webservices.httpConnTimeout" specifies the wait-time to connect to the external service.

In asynchronous invocations, you may use the Pick action for configuring the invocation timeouts.

Oracle Traffic Director : Extract Private Key to Decrypt and View SSL Snoop Data

Oracle Traffic Director (OTD) is the last software load balancer released and is based on iPlanet Web Server. It is a fast, reliable, and scalable layer-7 software load balancer that you can deploy as the reliable entry point for all HTTP and HTTPS traffic to application servers and web servers in your network. It leverage the NSS Shared DB for storing the private key and certificates for the SSL encryption and if you are looking to decrypt the SSL traffic using the private key, you would require to first extract it and the steps for it are as under:

For some reason, the pk12util that comes with OTD installation did not work for me so I have to move the cert9.db and key4.db onto my windows machine and follow the below steps:

1. Downloaded  NSS Tools for windows from here: NSS_Tools_x86_from_NSS_3.12.7 Tools.zip into C:\
2. Copied the key4.db and cert9.db to “C:\Users\nj\keys” folder
3. Go to command prompt (cmd C: ) and executue  c:\pk12util.exe -o C:\Users\nj\keys\cert.p12 -d sql:C:\Users\nj\keys -n "<>" (populated on SSL >> Server Certificates on OTD Admin Console)
4. Prompted for password, enter <>
5. This should create a cert.p12 under keys folder
6. Use OpenSSL to execute: openssl pkcs12 –in cert.p12 –out private.key –nocerts –nodes
7. Prompted for password, enter <>
8. private.key file should be created in the folder

 

 

 

Cisco VPN error : The VPN Client was unable to setup IP Filtering

If you are getting an error "The VPN Client was unable to setup IP Filtering" when trying to use the Cisco Any Connect client then here is the solution for you:

1. Save the file "BFE.reg" locally and then execute the file by double clicking
2. Click Start > Run > regedit
3. Browse to “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BFE\Parameters\Policy”
4. Right click on “Policy” and select permission
5. In the "Permissions for Policy" window, select advanced
6. Unselect “Include inheritable permission from this object’s parent”
7. Select Add from the Windows Security popup box
8. Remove Users and CREATOR OWNER
• Select Add button
• Enter in "NT Service\BFE" and select OK
• Give the Object the following Allow permissions: Query Value, Set Value, Create Subkey, Enumerate Subkeys, Notify, and Read Control
• Select OK to close all of the boxes
9. Reboot Windows
10. Connect with AnyConnect to test the connection

Weblogic setting wrong protocol in WSDL (Load Balancer terminating SSL)

In most of the architectures, the SSL is terminated at the hardware load balancer for performance reasons and allows the internal traffic to use HTTP for communication.

Client ---[HTTPS] --> Hardware LB (SSL termination) --- [HTTP] --> WLS (WebService)

The client will typically fetch the WSDL for the webservice hosted on WLS and use the endpoint available in the WSDL for invoking the webservice. So the calls for fetching the WSDL would happen as under:

Client (https://lbhost:lbhttpsport/URI?wsdl)  --- > Hardware LB (http://wlshost:wlshttpport?wsdl) --- WLS (set the endpoint in wsdl as frontendhost:frontendhttpport if provided or will return http://lbhost:lbhttpsport/URI)

Please note that the endpoint in the WSDL has the http protcol whereas the client is only used to call the LB on https protocol. The reason why WLS sets the protocol as http is because the request was recieved on http and there is no way for WLS to identify if the actual request was made on https.

To solve the issue, you need to set an extra header variable "WL-Proxy-SSL: true" at the load balancer so that WLS identifies the request is called on https. Also, you need to set the flag Weblogic-Proxy-Plugin Enabled at the WLS managed server.

Weblogic Service Migration (Issues and Workarounds)

Pinned services, such as JMS-related services, the JTA Transaction Recovery Service, and user-defined singleton services are hosted on individual server instances within a cluster—for these services, the WebLogic Server supports failure recovery with service migration. There is a lot of documentation and blogging on this topic and in this post I want to just cover two of the issues that you may face during the service migration setup:

Issue1: If you have multiple clusters within a domain and you have setup service migration (database leasing) for only some of the clusters in your domain then you may find that the other cluster members start throwing errors as under:

" #### <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <8bca0b730cda1738:17608ce6:1382c32b7b9: -8000-0000000000000002="-8000-0000000000000002"> <1340771329481> 'WseeJmsModule'.

java.lang.IllegalArgumentException: Cannot add Singleton Service M_MS1 (migratable) as SingletonServicesManager not started.  Check if MigrationBasis for cluster is configured."

 

Workaround: Configure Database leasing for all the clusters in the domain though no need to configure the full service migration but just the cluster level service migration.

 

Issue2: If you are using multi-datasource (MDS) for your service migration then you may see that everything is working fine but actually behind the scenes the service migration framework pins itself to first datasource in MDS list and it really does not failover to the other datasource in case if the first datasource goes DOWN. You can easily find if this is the case by issuing the following database query:

 

" select username, gv$sqlarea.inst_id, sql_text, gv$sqlarea.executions, gv$sqlarea.first_load_time from gv$session, gv$sqlarea where gv$session.sql_id = gv$sqlarea.sql_id and username ='<db_username>'; "

 

You see that all the sql to udpate the ACTIVE table are issued against the same RAC instance/datasource. If you shutdown the RAC instance/datasource where the service migration framework is pinned, it results that no more update happen to the ACTIVE table. Please note that the server periodically renews its lease by updating the timestamp in the lease table. By default a migratable server renews its lease every 30,000 milliseconds—the product of two configurable ServerMBean properties:

HealthCheckIntervalMillis, which by default is 10,000.
HealthCheckPeriodsUntilFencing, which by default is 3.

 

But there will no session created once the first datasource in the MDS configuration goes DOWN. Though, there will be lot of exceptions in the managed server logs but neither the migration happens nor the managed are able to secure a lease.

 

Workaround: There are couple of workarounds to resolve the issue:

1) Use TNS connect string for the datasource rather than using MDS

2) This is a reported bug (9365773) and should ask the Oracle support for a patch to fix the issue.

 

Also would like to mention some of the debug parameters specific for logging the service migration internals as under:

 

-Dweblogic.StdoutDebugEnabled=true

-Dweblogic.log.LoggerSeverity=Debug

-Dweblogic.log.LogSeverity=Debug

-Dweblogic.debug.DebugServerMigration=true

-Dweblogic.debug.DebugSingletonServices=true

-Dweblogic.debug.DebugUnicastMessaging=true

-Dweblogic.debug.DebugServerLifeCycle=true

-Dweblogic.slcruntime=true

-Dweblogic.slc=true

 

Please note that, both the above issue happened in Weblogic 10.3.4 & 10.3.5 and might have got fixed in later versions of Weblogic releases.