Question
Prime Therapeutics
US
Last activity: 26 Aug 2020 8:17 EDT
Update 7.2 is getting "SRVE0255E:" Error
Hi,
I am doing update from 7.1.7 to 7.2. I have run the 2 migrate and 2 update scripts. after that I am deploying new EAR file (prpc_j2ee14_ws.ear file). When I go to browser to log in. I am getting below error:
A WebGroup/Virtual Host to handle /prweb7/PRServlet/bjvNRSE1I9-FTK_4jYEW25SZpLAhAJCOhp6iEx8e-YQ%5B*/!STANDARD has not been defined." error.
I have searched for the error SRVE0255E error online. it says to point to web application to IBM Websphere application server's out-of-the-box "default_host" Virtual Host.Which is suggested by PEGA to use as well.
I am using default_host as virtual host as well but no luck .
Any Suggestions
Thanks in advance.
Accepted Solution
Prime Therapeutics
US
After Working with Kevin through SR. Here are the findings.
We were using ojdbc6.jar (Oracle JDBC version Proprietary information hidden.0), which has a bug that causes updates to fail in PEGA 7. Please see below screen shot from PEGA 7.2 platform support guide.
When we change the JDBC version to ojdbc7.jar (Driver version: Proprietary information hidden.0). System started up and PEGA login screen came up.
Premal,
Did the scripts actually execute successfully?
Also, can you tell me the serial number associated with the media you used for this? You'd find this in the file name of the update media, I believe it would either be "115007_Pega72-UPD.zip" or "115042_Pega72-UPD.zip."
Thanks!
Prime Therapeutics
US
Hi David,
Yes All the scripts execute successfully with following times.
1 migrate script : 108 min
1 update script : 100 min 10 sec
2 migrate script: 2 min 08 sec
2 update scrip: 106 min 33 sec
all builds were successful.
Here is the media serial numner. 115007_Pega72-UPD.zip.
Thanks
Pegasystems Inc.
US
looks like the rules/data schema bindings are not defined correctly:
2/18/16 13:06:51:152 CST] 00000065 PRBootstrapDa Z com.pega.pegarules.internal.bootstrap.PRBootstrapDataSource Bootstrap datatables schema: null
Check the installation guide. there is specific section talking about that.
Pegasystems Inc.
US
please share your screenshots including datasource configuration and naming bindings, your startup clearly shows that the engine did not pickup the intended schemas.
Pegasystems Inc.
US
what is the jndi name for the datasource, this is the problem - should be jdbc/PegaRULES out of the box.
[2/18/16 13:06:51:171 CST] 00000065 PRBootstrapDa E com.pega.pegarules.internal.bootstrap.PRBootstrapDataSource Unable to obtain DataSource for java:comp/env/jdbc/PegaRULES; com.ibm.websphere.naming.CannotInstantiateObjectException: A NameNotFoundException occurred on an indirect lookup on the name java:comp/env/jdbc/PegaRULES. The name java:comp/env/jdbc/PegaRULES maps to a JNDI name in deployment descriptor bindings for the application performing the JNDI lookup. Make sure that the JNDI name mapping in the deployment descriptor binding is correct. If the JNDI name mapping is correct, make sure the target resource can be resolved with the specified name relative to the default initial context. [Root exception is javax.naming.NameNotFoundException: Context: tpega07sand/nodes/tpega07sand-node01/servers/tpega07sand-sysmgmt01, name: jdbc/PegaRULES: First component in name PegaRULES not found. [Root exception is org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]]
Pegasystems Inc.
US
ah, this should be defined at the cluster level (same for PegaWorkManager and naming bindings, only pega temp dir needs to be defined at the server level).
Pegasystems Inc.
US
but did you also define a datasource at the server level, which is what is shown in the previous screenshot. Delete that one if not needed. Double check all the servers in your cluster.
Pegasystems Inc.
US
It is clear your jndi resources are not bound during the server start, not just jdbc/PegaRULES, I do not even see url/initialization/explicittempdir etc. I would suggest you make sure all nodes are fully synchronized and restart both deployment manager and node agent. Look for stuff similar to these during startup:
[1/28/16 17:08:51:718 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding Pegarulesv719st_CF as eis/jdbc/PegaRULES_CMP
[1/28/16 17:08:51:724 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding Peganone as url/pega/none
[1/28/16 17:08:51:761 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding Pegarulesv719st as jdbc/PegaRULES
[1/28/16 17:08:51:770 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding pegaworkmanager as wm/PegaWorkManager
[1/28/16 17:08:51:779 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding DefaultEJBTimerDataSource as jdbc/DefaultEJBTimerDataSource
[1/28/16 17:08:51:788 EST] 00000001 ResourceMgrIm I WSVR0049I: Binding pegatempdir as url/initialization/explicittempdir
After all these you may to run the Websphere dumpNameSpace tool: IBM Knowledge Center
Like I said, create a SR and have someone working with you directly.
Pegasystems Inc.
US
Hi Premal,
Let us know the number of the SR should you open one so that we may tie the troubleshooting done in this post to the SR directly!
Pegasystems Inc.
US
OK, can you run the dumpNamespace following the IBM link? If you want, you can ask the engineer to route the SR to me so that I can work with you directly.
Pegasystems Inc.
US
Update:
Worked with Premal yesterday and went through all app server configuration. All jndi namespace Issues have been fixed (mainly due to some misconfiguration/deployment). Now all the jndi bindings are correctly identified during server startup. The current issue is due to incorrect rulebase update (e.g., missing pr_engineclasses table). Premal is going to work with his colleague to rerun update and then server should be able to startup.
Updated: 23 Feb 2016 19:57 EST
Prime Therapeutics
US
Pegasystems Inc.
US
please attach a complete log file (use attachment not copy/paste) for a clean restart. From the log, you should be able to see the schemas used for both rules and data schema. Also do a query from sql client tool and post the result:
select distinct pzcodesetversion from <rules schema>.pr_engineclasses where pzcodeset = 'pega-enginecode';
Prime Therapeutics
US
Here is the database sql results.
select distinct pzcodesetversion from pegasand_rules72.pr_engineclasses where pzcodeset = 'pega-enginecode';
| PZCODESETVERSION | |
| 1 | 07-10-23 |
| 2 | 07-10-15 |
Pegasystems Inc.
US
Looks like all the right schemas are used except that the query above is not executed. Can you try to use the latest jdbc driver (ojdbc7.jar)? if still not working, create a new SR request assigning to me, we can go through more details tomorrow.
Prime Therapeutics
US
Kevin, for (ojdbc7.jar) I have to check with the DBAs. but is 7.2 is different than 7.1.7, because my all other environments are running ojdbc6.jar and they are working completely fine. I will check with DBA, and if available I will try with that tomorrow.
Prime Therapeutics
US
Accepted Solution
Prime Therapeutics
US
After Working with Kevin through SR. Here are the findings.
We were using ojdbc6.jar (Oracle JDBC version Proprietary information hidden.0), which has a bug that causes updates to fail in PEGA 7. Please see below screen shot from PEGA 7.2 platform support guide.
When we change the JDBC version to ojdbc7.jar (Driver version: Proprietary information hidden.0). System started up and PEGA login screen came up.