Service Desk Practitioners Forum
cancel

ACES Warning - and Seeing Strange DB Rule behavior

Highlighted
Marty Brown_1
Super Contributor.

ACES Warning - and Seeing Strange DB Rule behavior

Hi all: I'm just starting at a new client site. They're at HPSD 4.5 SP21, but the place has not followed good practices to ACES configuration changes between their TEST and PROD environments.

Now, when using ACES to try to copy a DB Rule from TEST to PROD, I'm getting the following warning. Can anybody shed light on A) how this would have happened, but more to the point, B) how to rectify this.

I'll copy the ACES Log file.

Naming conflict, entity 'EntityUsage' has two attributes with the same name 'ItemType'
but with different oid's: '28' and '633318801539612'

The DB rule I'm trying to create does get created, but any attempt to update it (e.g. simply BLOCK it), causes the following:

- Error message indicating that all of the Concurrent license Seats have been used up

- Multiple occurrences of the following Error in the Server log:

Mon, 17/12/2007 09:04:53 load of repository items failed for id: 281486617152551
Mon, 17/12/2007 09:04:53 java.lang.NullPointerException
at com.hp.ifc.rep.rules.dbrules.AppDBRules.setInfos(Unknown Source)
at com.hp.ifc.bus.AppSrvRepository.loadInfos(Unknown Source)
at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.hp.ifc.bus.AppSrvDispatch.invoke(Unknown Source)
at com.hp.ifc.bus.AppSrvDispatch.invoke(Unknown Source)
at com.hp.ifc.rep.AppRepository.refresh(Unknown Source)
at com.hp.ifc.rep.AppAbstractInfoManager.refreshData(Unknown Source)
at com.hp.ifc.rep.AppAbstractInfoManager.getAllInfo(Unknown Source)
at com.hp.ifc.rep.rules.dbrules.AppDBRules.setInfos(Unknown Source)
at com.hp.ifc.rep.AppAbstractInfoManager.cacheUpdate(Unknown Source)
at com.hp.ifc.rep.AppCacheManager.handleMessage(Unknown Source)
at com.hp.ifc.rep.AppCacheManager.setAsUnFresh(Unknown Source)
at com.hp.ifc.rep.AppCacheManager.setAsUnFresh(Unknown Source)
at com.hp.ifc.bus.AppServerEntity.save(Unknown Source)
at com.hp.ifc.bus.AppServerEntity.save(Unknown Source)
at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.hp.ifc.net.itp.AppItpRequest.localInvoke(Unknown Source)
at com.hp.ifc.net.itp.AppItpRequestHandler.process(Unknown Source)
at com.hp.ifc.net.tcp.AppTcpConnection.processRequest(Unknown Source)
at com.hp.ifc.net.tcp.AppTcpThread.run(Unknown Source)

- Hitting F5 on the list of DB rules in the Admin Console results in seeing not the Names of the Rules anymore but a list of OIDs. Very strange.

- I can return things to normal by deleting the ill-behaving DB rule, by its OID, directly from the rep_javaobjects table in the database.

The client has indicated that this situation with trying to modify DB rules in PROD has been the case since they went live, and that is why they have not used ACES. Their practice has been to code New rules directly in PROD, and if changes are needed, they DELETE the old rule and re-create it from scratch.

Interestingly enough, this problem does Not happen in their TEST environment.

Points to Any and All who can provide ideas on how to set this PROD environment back up properly. I'm really stumped on this one and could use some ideas from all of you Forum Gods.

Thanks and Happy Holidays!
11 REPLIES
Mark O'Loughlin
Acclaimed Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

Hi Marty,

try this approach to sync the environments back up.

Make a full copy of the production database. Take it and place it in the test environment. Connect the test OVSD server to this copy of the prod database.

Now the two should be the same again. Now create the rule again from scratch or create a new rule in the test environment. Now use ACES to export it from test and import it to prod. Do you still get the errors /issues with Aces?


What type of DB is in test and prod. I have seen sites with SQl in test and Oracel in prob.
Marty Brown_1
Super Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

Both TEST and PROD are Oracle Databases...

Currently, The TEST database instance is a recent clone of PROD. For various reasons, it isn't going to be very easy for us to clone PROD back over our TEST environment at this time.

What's so strange is that the issue where updating a DB rule causes the system to 'loop' and consume all of the Concurrent seats happens only in our current PROD and not in our current TEST environment. I can update the same (OID is the same too) DB rule in TEST, and all is fine. Try doing that to the rule as it sits in PROD, and the errors occur.

So, since the databases are recent clones of one another, this makes me wonder if there might be something different with the way that the HPSD App itself was built between their TEST and PROD. Any ideas on what to check?

Screenshots of the very strange situation where the GUIDs showing up in the Admin console when trying to view DB rules after the 'looping' error occurs are attached.

Other things I've tried:
- Clearing Server Cache
- Running the SD45ViewRules.exe Rule checker program as part of itsm007071 (there were initially errors, but the bad records have been removed from the DB)
- Prayer (can't hurt, right?) :)

Thanks!!
Alok Shrotri
Honored Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

Wild Guess!!

What is the Java Version? Any differences?

Regards,
Alok Shrotri
Ruth Porter
Acclaimed Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

Hi there,

One idea - rename the rule on the TEST DB and re-do the ACES.

Then when you have them both on the PROD, block the onbe you do not want.

To use ACES successfully you must ALWAYS creat on TEST and take to PROD and never create anything in system admin directly on the PROD; once the databases are out of step you cannot guarantee ACES will work.

See attached PDF from HP.

Hope this helps, Ruth
http://www.teamultra.net
Marty Brown_1
Super Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

Thanks for the ideas!

Answers:

Java Version is the same on both TEST and PROD: 4.2.08-b03

* * *

To try to get 'good' rules into PROD I've done the following Scenarios:

A) In TEST, Copy/Paste a rule (In other words, create a rule with a brand new OID). ACES the COPY into PROD. This always works--I can always ACES a rule into PROD. But, try to modify the new rule in PROD (like try to block/unblock it). The errors occur with SOME new rules, but not with all.

B) In PROD, Create a brand new rule. I am always allowed to create the rule. Then, try to modify that rule. The errors occur with SOME of these rules, but not with all.

After thinking about this all weekend, what my 'plan' was to get around the error was to completely re-code, by hand, all of the DB rules, but now in testing today, that isn't foolproof either (because this is basically Scenario "B").

So, I'm still stumped. Something "environment" related is different between my PROD and TEST instances. Although I could be wrong, my gut tells me that it isn't related to the Databases, because TEST and PROD DBs are recent clones of one another and according to the customer, this problem goes back way further than the last clone. So, that points me to something in the PROD server's Application layer, but darned if I know what... These errors happen all the time in PROD, but have never been seen in TEST...

If this matters, our TEST server has half a gig of RAM and our PROD server has 2GB. The HPSD expanded memory settings have been implemented in PROD but not in TEST. Both TEST and PROD are VMWARE Virtual server instances.

Thanks again to all for your thoughts and ideas!

~Marty
George M. Meneg
Acclaimed Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

It's pretty strange error considering that 'ENTITY USAGE' has nothing to do with db rules.

Entity usage is introduced in SP20. It's the features that OVSD notifies if another person is viewing/modifying the item you try to open. I guess that something went wrong at the upgrade to the SP you're in.

There are two attributes with name "Item Type" on ifc_attributes. The first is with oid 633318801539612 and its atr_ent_oid is 633318801539606 (that is the "Entity Usage"). The other have atr_oid=28 and atr_ent_oid=2 ("Entity")

Please run the following query to the production system and then to the test system:

select * from ifc_attributes where
atr_ent_oid=(select ent_oid from ifc_entities where ent_name='Entity Usage')
and post the result here.

Normally this should return 6 columns.

menes fhtagn
stoney_2
Respected Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

Hi,
the entity usage error message can be ignored. It is a meaningless error, and is fixed in a later fix. SP23 i believe

Rules, they always go skewiff, you have to run the progam or fix manually (painfully slow) as well as clear cache. Frommemory it is also fixed in later SP. We even have to fix them after a restore.



its a long way to the top if ya wanna
Err_1
Acclaimed Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

Hello,

there is a known problem after SP20 (resolved in SP23) where there is a naming conflict error when doing ACES importing; this is very easy to identify when you get the following error in the log (refer to ITSM008974):

â EntityUsage' has two attributes with the same name 'ItemType' but with different oid's: '28' and '633318801539612

http://openview.hp.com/ecare/getsupportdoc?docid=ITSM008974

Regards,
Randall Barrantes
SW Support Delivery Manager
Marty Brown_1
Super Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

Thanks to Everybody for your assistance!

George: I'll post the results of the SELECT statement you posted when I return to the office (in about 12 hours)

So, with all of your help, I now conclude that the ACES log warning message that I am getting is basically benign and not worth worrying about. I was wrong to assume that it had anything to do with the real problem that I've got, which is that when I try to modify DB rules in PROD, that my GUI session gets locked up, I see OIDs instead of the Names of the DB rules in the Admin Console, (See the attachment), and I can't proceed until I delete the now bad/stuck DB rule directly from the database.

Please take another look at the initial item in this thread, and read past the part about the ACES Warning message. Any help about the Server Log errors and the horked DB rules would be greatly appreciated (and rewarded with Points).

This Forum is the greatest! Thanks!

~Marty
Marty Brown_1
Super Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

George: Posting the results of running the SQL statement as your requested.

PROD is first.
Marty Brown_1
Super Contributor.

Re: ACES Warning - and Seeing Strange DB Rule behavior

Here is the results when run against TEST.

Again, Thanks!!