OBIEE Logs and Configuration files
bi_server1.log & bi_server1-diagnostic.log
(bi_server1.out & access.log are also captured in this directory)
[$FMW_HOME]/user_projects/domains/bifoundation_domain/servers/bi_server1/logs
nqserver.log & nqquery.log
[$FMW_HOME]/instances/instance1/diagnostics/logs/OracleBIServerComponent/coreapplication_obis1
sawlog.log
[$FMW_HOME]/instances/instance1/diagnostics/logs/OracleBIPresentationServicesComponent/coreapplication_obips1
NQSConfig.INI & DBFeatures.INI
[$FMW_HOME]/instances/instance1/config/OracleBIServerComponent/coreapplication_obis1
instanceconfig.xml & credentialstore.xml
[$FMW_HOME]/instances/instance1/config/OracleBIPresentationServicesComponent/coreapplication_obips1
config.xml
[$FMW_HOME]/user_projects/domains/bifoundation_domain/config
system-jazn-data.xml
[$FMW_HOME]/user_projects/domains/bifoundation_domain/config/fmwconfig
Saturday, November 30, 2013
Friday, July 26, 2013
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$
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$
Thursday, July 25, 2013
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.
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).
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
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
e.g in my case:
?123456789
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
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):
?123456789101150000 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/
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
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/
Wednesday, July 24, 2013
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.
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.
Subscribe to:
Posts (Atom)
