FW: ITSM Issue with Sandbox Enablement

[Ben Chernys]

Hi Folks
 
I am having a ticket raised with BMC for this one but I just thought I'd pass 
it to the list for any thoughts that may come my way.  It has me in a bit of a 
quandary and I thank anyone that can help me resolve it or work-around it.
 
I have placed the log zip file (88KB) here  because the list software blocks my 
attachment.    
www.softwaretoolhouse.com/_logs/ARUSERC2.ZIP
 
PlatformSparc Sun Fire  V240
OS   Solaris 5.10
DB   Oracle 10g2
ARS 7.1patch 5
ITSM7.0.3 patch 7
 
Cheers
Ben Chernys

Senior Software Architect
Software Tool House Inc.

Canada / Deutschland / Germany
Mobile:  +49 171 380 2329GMT + 1 + [ DST ]
Email: 
mailto:ben.cher...@softwaretoolhouse.com
Web:   
http://www.softwaretoolhouse.com

A free notepad for Diary fields:
  
http://www.softwaretoolhouse.com/downloads/DiaryFieldEditor.htm
An ARS API scripting tool used for migrations, integrations, imports, reports, 
extracts, batch jobs:
  
http://www.softwaretoolhouse.com/products/SthMupd
  
 
 __ 
Von:Chernys, Ben  
Gesendet:   Mittwoch, 28. Januar 2009 09:37 
An:  Ben Chernys
Cc: 
Betreff:ITSM Issue with Sandbox Enablement 

When we use the Sandbox feature (btw I had to put a fix in for our Geman 
clients - Sandbox enablement is ignored if you are not running an English 
client - any attributes (of our hand-constructed classes using default Admin 
defined field ids) that are NOT in BaseElement (or rather 
BMC.CORE:BMC_MainFrame)  do NOT get pushed to the Sandbox instance. 

The Sandbox job has NULL Defer = Yes in the OOTB job. I can see why. If you 
turn this off (which is a bug that the OOTB is NOT off - restricting you from 
nullifying an attribute and then causing a mis-match between the two instances 
in the datasets) what happens is all the non-BaseElement (MF) attributes become 
NULL even when they are not touched. 

I believe the error is manifested by the filter ASI:SHR:All_600_PushToBMCForm 
which uses a sample schema where the push target is in a DO field. The filter 
has the "by ID" check-box checked. The Log describes the fields pushed and 
those target fields include those fields for the real target schema but the 
values for these fields are all null. Have you seen this behaviour? You should 
notice it if you take any class which other than BMC_Mainframe and change an 
attribute from that class (which field id is NOT in BMC_Mainframe). 

The problem is isolated to retrieving the values of fields as the target fields 
seem to be complete. I have checked the database (filter_push) and will need to 
have a play with the API to see what actually is set for a "by like id"push 
fields. It is possible, I suppose, to build a better sample form with all of 
our and OOTB field ids in it. 

from filter 
"ASI:SHR:All_600_PushToBMCForm", 3093, 1226599817, "Remedy", "panacea", 1, 600, 
20, 1, 1, 2, 
"ZODP+HGF8UUQFMpti/TK3KBO9J67T2saQn68e9TkISfKv8K219ABUBhboLdYUUv0UBd00rC2s98yWtiDld8iwnwpzvEXvjEb",
 "4\6\99\301170700\2\0", NULL, "1144618550♦BMC♦Copyright (c) 1991 - 2006 BMC 
Software, Inc. all rights reserved
BMCVer=7.00.00♥", NULL, "4\60006\4\0\\60008\40\0\60009\4\0\\60010\4\0\\", NULL, 
NULL, 0, 0 

from filter_push 
3093, 0, 98, 
"1...@\11\$301170700$\1\98\4\1\1\179\99\179\4\5\102\1\@\...@\1\98\0\4\5\", 
NULL, "BMC.CORE:BMC_Mainframe", "@"
3093, 1001, 98, 
"1...@\11\$301170700$\1\98\4\1\1\179\99\179\4\3\102\1\@\...@\1\98\0\4\3\", 
NULL, "BMC.CORE:BMC_Mainframe", "@" 

As far as I can tell there will be two work-arounds possible: 1) a better 
sample form. or 2) a filter for each class replacing the single filter above. 

The conclusion or direction has changed since I implemented the following test. 
 I replaced the above filter with one using the exact form that was 
participating in the Push Fields.  Same effect.  It now looks that this 
SandboxCreate CI Name causes untraced actions in the hiddent Invoke External 
Filter CMDB Processes and that it is likely that the error is there.

I have attached a client trace file (AL, Filter, SQL, API).  We have turned off 
(deactivated) any non-OOTB filters.  The ASI:SHR:All_600_PushToBMCForm has been 
changed to specify the same form as the value of the OS Schema field in the 
trace.


093411.591 i ArQryGet returns 1 records for select name , queryshort from 
filter where queryshort like '%Reconcile%' 
"001""002" 
<>SQL row: 1 
Col 0: ASI:SHR:SandboxCallReconEngineRelation_999 
Col 1: 4\1\99\100076\2\4\9\Reconcile\ 

093422.294 i ArQryGet returns 2 records for select name , queryshort from 
filter where queryshort like '%Reconclie%' 
"001""002" 
<>SQL row: 1 
Col 0: AS

FW: ITSM Issue with Sandbox Enablement

[Ben Chernys]

That is correct.  The Class Manager console was used.  cmdb2asset is no longer 
used.  The functionality is done with other processes now.  But yes, all done 
with OOTB facilities.  The IDs were auto-assigned.  (bad!) and (worse) so where 
the class guids!  My OOTB VM "seems" to work as well.  BUT, I have not made any 
new classes there and done a real experiment.
 
Cheers
Ben

  _  

From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of Lyle Taylor
Sent: January 28, 2009 10:32 PM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM Issue with Sandbox Enablement



Ben,

 

You said something that I would like clarification on:

 

any attributes (of our hand-constructed classes using default Admin defined 
field ids)

 

(italics added)  Just to be certain I’m understanding things correctly, did you 
create these classes using the CMDB console using the functionality there for 
creating classes and adding attributes to them, or did you do any of this work 
in the Admin tool?  While I haven’t added any new classes, I have added a fair 
number of attributes to existing classes (although we used IDs specified from a 
specific range of IDs that we were using, rather than letting the system 
auto-assign IDs), and we never had a problem with the system not bringing these 
attributes into the sandbox, which is something that I think should be someone 
analogous to what you’re trying to do in the end.  While I’m not an expert on 
what happens when you use a sample schema, I would expect that the fact that 
“by ID” is selected, it should bring across all fields with matching IDs 
regardless of whether or not they’re in the sample schema – which it seem would 
have to be the case or the majority of the OOB classes would have this same 
issue.

 

Well, I guess there’s no useful information in the paragraph above.  I guess I 
really just want to confirm that the classes were all created using the CMDB 
console exclusively, and that any AST forms used to work with those classes 
were created using the CMDB2Asset utility so that the IDs of the fields on the 
asset forms and the CMDB forms all match up, regardless of whether they’re OOB 
or custom.

 

Lyle

 

From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of Ben Chernys
Sent: Wednesday, January 28, 2009 1:57 PM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM Issue with Sandbox Enablement

 

**  

Thanks Guys,

 

I agree with you.  I noticed the part that doesn't make sense but believe it or 
not I have a reasonable reason for using it.  As for auditing, we've had our 
share of issues with it but are (over) using it.

 

I disabled the delete activity in the Sandbox reconciliation job so that when a 
CI in Production (Gold?) is touched by a person, I can have our standard 
reconciliation job basically use the equal Sandbox CI at a higher precedence 
and then more or less cancel the normal discovered CI in the recon job.  When 
that normal discovered CI has "caught up" to the human modified CI, in a set of 
configured fields I might add, then the Sandbox CI is deleted and the CI is no 
longer human modified and participates in reconciliation updates as normal.  I 
also cannot add an attribute indicating the human modification state to 
BaseElement.

 

The Sandbox indeed makes no sense whatsoever as implemented with the OOTB 
workflow.  The Updated CI is pushed (supposedly) to the Sandbox, and then 
immediately reconciled to production AND deleted from Sandbox.  Also note the 
comments about the NULL Option in the OOTB Job.  This may be there to cover the 
issue I encountered below.

 

We now have a ticket with BMC but alas, I am going to have to do something to 
make it work sooner than I expect a response or a fix.  Perhaps the Overlay 
feature works better?

 

Cheers

Ben

 

  _  

From: Action Request System discussion list(ARSList) 
[mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault
Sent: January 28, 2009 9:15 PM
To: arslist@ARSLIST.ORG
Subject: Re: ITSM Issue with Sandbox Enablement

** 

I totally agree with Lyle.

 

It just does not make sense to have a sandbox that will be immediately 
reconciled to production dataset. Besides restricting the updates via 
permissions or field properties, I would add that enabling auditing on the 
fields that can be updated is a good complement, from a control/audit 
perspective. So with access control and auditing, you really don't need a 
sandbox, and you are going to gain a lot in terms of reducing complexity, 
maintenance, etc.

 

-Guillaume

 

__Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are" html___ 



NOTICE: This email message is for the sole use of the intended recipient(s) and 
may contain confidential and privileged information. Any unauthorized review, 
use, disclosure or distribution is prohibited. If you are not the intended 
recipient, please contact the sender by reply email and destroy all copies o