Using weblogic.Admin utility to PING with Weblogic 11g

Login to the Admin Server as Weblogic User

Step1 :

 soadev03@ngmlx550$ export CLASSPATH=/var/domain/soa_dev01/WEBLOGIC_HOME/server/lib/weblogic.jar


Step2 :
soadev03@ngmlx550$ ls -lrth /var/domain/soa_dev01/WEBLOGIC_HOME/server/lib/weblogic.jar

-rwxr-x--- 1 weblogic weblogic 35M Jul 18 2012 /var/domain/soa_dev01/WEBLOGIC_HOME/server/lib/weblogic.jar

Step 3:
soadev03@ngmlx550$ java -Dweblogic.security.SSL.ignoreHostnameVerification=true -Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName=/var/domain/soa_dev03/keystore/CapitalOneWebLogicTrustKeyStore.jks -Dweblogic.security.CustomTrustKeyStorePassPhrase=password -Dweblogic.security.CustomTrustKeyStoreType=JKS -Dweblogic.security.SSL.allowSmallRSAExponent=true weblogic.Admin -url t3s://ngmlx550:2590-username weblogic -password Tru123 PING

<26-jul-2013 11:55:40="" bst="" clock="" o="">

<26-jul-2013 11:55:41="" bst="" clock="" o="">

Sending 1 ping of 100 bytes.



RTT = ~377 milliseconds, or ~377 milliseconds/packet

soadev03@ngmlx550$

two-phase commit and JTA time out

A feature of transaction processing systems that enables databases to be returned to the pre-transaction state if some error condition occurs. A single transaction can update many different databases. The two-phase commit strategy is designed to ensure that either all the databases are updated or none of them, so that the databases remain synchronized.



Database changes required by a transaction are initially stored temporarily by each database. The transaction monitor then issues a "pre-commit" command to each database which requires an acknowledgment. If the monitor receives the appropriate response from each database, the monitor issues the "commit" command, which causes all databases to simultaneously make the transaction changes permanent.


JTA Timeout

Specifies the maximum amount of time, in seconds, an active transaction is allowed to be in the first phase of a two-phase commit transaction. If the specified amount of time expires, the transaction is automatically rolled back.

MBean Attribute:

JTAMBean.TimeoutSeconds
Minimum value: 1
Maximum value: 2147483647


the early days of computing, there was no need for distributed transactions. As number of applications increased, synchronization of the data become an important issue. Companies paid a lot to maintain synchronized systems in terms of data flow. As a result, the 2 phase commit protocol referred to as XA(eXtended Architecture) arose. This protocol provides ACID-like properties for global transaction processing. Throughout this article, I will try to explain details of XA transactions and use of XA Transactions in Spring framework.




2 phase commit protocol is an atomic commitment protocol for distributed systems. This protocol as its name implies consists of two phases. The first one is commit-request phase in which transaction manager coordinates all of the transaction resources to commit or abort. In the commit-phase, transaction manager decides to finalize operation by committing or aborting according to the votes of the each transaction resource. We will next move on to implementation details of 2PC protocol.

Increase the session timeout of Oracle BPM Worklist app

The Oracle BPM Worklist app is a part of the Oracle SOA Suite. Working with the Worklist app is very annoying, because the default timeout is very short (seconds!). So after getting a cup of coffee or reading a mail you have to login again.


Solving this problem seems quite easy by increasing the session timeout in your (generated) ADF human task or in the worklist app in the weblogic console, but it all doesn’t work.

The solution for this annoying issue is quite easy, once you know where and how. Here is the trick.

First we need to create a deployment plan for the worklistapp. When you already have one, you can skip step 1 to 5 and continue with step 6.

1. Navigate in the Weblogic console to “Deployments” (in the menu on the left) and search in the list for “worklistapp”.



2. Expand the worklistapp [+] and under Modules click on Web Application “/integration/worklistapp”.



3. Go to the “Configuration” tab (subtab “General”).



4. Change the value of the “Session Timeout (in seconds)” to something else (it must be a different value).



5. Save and follow the weblogic directions to create a deployment plan (plan.xml).



6. Locate you deployment plan by going the “Deployments” page and search again for “worklistapp”.



7. Instead of expanding, click on the “worklistapp”.



8. You can see the location of your deployment plan under tab “Overview” after property “Path”.

e.g. /apps/Oracle/Middleware/Oracle_SOA1/soa/Plan.xml



9. Go to this location on the machine (server) where the BPM Worklist (SOA Suite) is installed.



10. Make a copy of the plan (e.g. Plan2.xml), leaving the original one as ‘backup’.



11. Edit the new deployment Plan2.xml file.



12. Search in the beginning of the file for the setting with the name SessionDescriptor_timeoutSecs_xxxxxxxxxxxxxx where x is a digit

(xpath: /deployment-plan/variable-definition/variable/name)

Edit the value for the timeout you desire. The timeout value you define proves to be in minutes (not seconds, despite of the name)!



e.g. in my case, I’ve set the timeout to 45 minutes:



?1234 SessionDescriptor_timeoutSecs_13064193293970 45

13. Search for the node “module-override” of the “worklist.war” module (xpath: /deployment-plan/module-override/module-name).



14. In this “module-override” node, there is a child node “module-descriptor” that contains child node “root-element” with value “web-app”, probably the last child node of node “module-override”).

Note: Don’t confuse it with node “module-descriptor” with “root-element” node “weblogic-web-app”.



15. When you’ve found the correct “module-descriptor” node, add the following child nodes after child node “uri”, which should have value “WEB_INF/web.xml”, and replace the xxxxxxxxxxxxxx with the same digits you have found in step 12:



?12345 SessionDescriptor_timeoutSecs_xxxxxxxxxxxxxx /web-app/session-config/session-timeout replace

e.g in my case:



?123456789 web-app WEB-INF/web.xml SessionDescriptor_timeoutSecs_13064193293970 /web-app/session-config/session-timeout replace

16. Save the file.



17. Go back to the Weblogic console and again go to the “Deployments” page.



18. Select “worklistapp” [v]



18. Stop the “worklistapp” with the Stop button.



19. Select “worklistapp” [v] again.



20. With the “Update” button use your new deployment plan (e.g. Plan2.xml)



Note: When there are problems (errors) with updating other applications as well, stop the other applications and restart them after the update of the “worklistapp”.



21. Start the “worklistapp”.



Test:

You can check if it works bij checking the session timeout of a session.

22. First login into the BPM Worklist to create a session.



23. In the Weblogic admin console, go to the “Deployments” page and search for the “worlistapp” again.



24. Expand the “worklistapp” [+] and under Modules click on Web Application “/integration/worklistapp”.



25 Click on tab “Monitoring” and select subtab “Sessions”.



26. If you’ve done it correctly, the “Max Inactive Interval” is set to your value multiplied by 60 (minutes to seconds).

e.g. in my case, it’s 2700 (45 * 60).

SOA 11g : Configuring Transaction timeout in BPEL

Transaction timeout can be configured for BPEL in 11g using the below properties.




1. SyncMaxWaitTime



Maximum time BPEL process wait before returning result to client(or another Sync process)



To set this property



a. Login to EM console



b. Expand SOA and right click on “soa-infra”



c. From context menu, select SOA Administration –> BPEL properties



d. Click on “More BPEL Configuration properties…”







2.Transaction Time-out for BPEL EJB’s



The following EJB’s need to be configured for transaction time outs.



BPELActivityManagerBean

BPELDeliveryBean

BPELDispatcherBean

BPELEngineBean

BPELFinderBean

BPELInstanceManagerBean

BPELProcessManagerBean

BPELSensorValuesBean

BPELServerManagerBean

To change time out for these beans ,



a. Login to Administration Console



b. Click on Deployments



c. Expand soa-infra –> EJB’s







d. Click on EJB for which you want to change the timeout



e. Click on Configuration



f. Change value for field “Transacion Timeout”



g. Click Save.







3. Global Transaction Timeout



This property is timeout in seconds for active transactions. After this time, if the transaction is still “Active”, then it gets rolled back.



To change this value



a. Login to Administration Console



b. Expand “Services” –> Click on “JTA”



c. Click on “JTA” tab if it’s on a different tab



d. Change value for field “Timeout Seconds”







Very Important :



SyncMaxWaitTime < BPEL EJB's transaction timeout < Global Transaction Timeout









Restart Weblogic server .



Click here for more reference : http://soadiscovery.blogspot.co.uk/2011/04/soa-11g-configuring-transaction-timeout.html

Timeouts in Oracle SOA Suite 11g

Timeouts in Oracle SOA Suite 11g


Some time ago… at a Oracle SOA 11g project, we had to call an external webservice which took 1 to 5 minutes to respond. The composite calling this webservice was called by another composite from a BPEL process. As you might guess, we got an timeout resulting in faulted instances.

Increasing the timeout time wasn’t as easy as I expected, because it’s not one timeout setting that had to be increased, but a total of five timeout settings! To document this for myself in case I run into it again and to help others with the same problem I’ve wrote it down in this blogpost. If you are searching for how to increase the session timeout of the BPM worklist, go to this blogpost.



The five timeout settings in Oracle SOA Suite 11g:



1.In the composite.xml of the composites calling the long running webservice and the composites calling these composites (and thus the whole chain of calling composites), set the webservice binding property for read timeout (and optional the connection timeout) in the reference declaration (value in milliseconds):

?1234567891011 50000 500000 WSDLDriven

2.For the BPEL timeout set property SyncMaxWaitTime (value in seconds) in the SOA Suite console (Oracle Fusion Middleware Control): In the navigation menu on the left expand the “SOA” folder and select item “soa-infra (soa_server1)” just below it. Then in the top of the details screen on the right expand the drop down menu “SOA Infrastructure” and select “SOA Administration” -> “BPEL Properties” . The “BPEL Service Engine Properties” screen opens. Click on link “More BPEL Configuration Properties…” at the bottom of this screen. Now the “Application Defined MBeans: BPELConfig:bpel” screen opens and finally you can edit the setting SyncMaxWaitTime (scroll down, setting #36 in list).



3.Set timeouts in the soa EJB’s: Open the Weblogic console and click in the navigation menu on the left on “Deployments”. Expand “soa-infra” by clicking on [+] and expand node “EJBs” in the same way. Increase the “Transaction Timeout” (value in seconds) in the “Configuration” tab for the following EJB’s by clicking on them:

•BPELEngineBean

•BPELDeliveryBean

•BPELActivityManagerBean

•BPELServerManagerBean

•BPELProcessManagerBean

•BPELInstanceManagerBean

•BPELFinderBean

4.Increase the JTA timeout in the Weblogic console by selecting “soa_domain” in the navigation menu (top item) on the left. Then select tab “Configuration” and subtab “JTA”. The first setting is the “Timeout Seconds” (value in seconds).



5.To solve “HeuristicMixedException” timeouts, set the “XA Transaction Timeout” of the soa jdbc connection to 0 seconds (means inherit) by expanding “Services” -> “JDBC” and select “Data Sources”. In the screen on the right select “SOADataSource” from the list and select tab “Configuration” and subtab “Transaction”. Enable setting “Use XA Datasource Interface” and setting “Set XA Transaction Timeout” and set setting “XA Transaction Timeout:” to 0 (inherit globale Weblogic transaction timeout).

Refere link for more information  :http://technology.amis.nl/2011/11/18/timeouts-in-oracle-soa-suite-11g/

stage/no stage/external-stage in WEBLOGIC

Stage mode


The Administration Server copies the archive files from their

source location to a location on each of the targeted Managed Servers that

deploy the archive. For example, if you deploy a J2EE Application to three

servers in a cluster, the Administration Server copies the application archive

files to each of the three servers. Each server then deploys the J2EE

Application using its local copy of the archive files.

Stage mode is the default mode when deploying to more than one WebLogic Server

instance.



Nostage mode

The Administration Server does not copy the archive files from

their source location. Instead, each targeted server must access the archive

files from a single source directory for deployment. For example, if you deploy

a J2EE Application to three servers in a cluster, each server must be able to

access the same application archive files (from a shared or network-mounted

directory) to deploy the application.

Nostage mode is the default mode when deploying only to the Administration

Server (for example, in a single-server domain). You can also select nostage

mode if you run a cluster of server instances on the same machine.



- External_stage mode



External_stage mode is similar to stage mode, in that the

deployment files must reside locally to each targeted server. However, the

Administration Server does not automatically copy the deployment files to

targeted servers in external_stage mode; instead, you must manually copy the

files, or use a third-party application to copy the files for you.