Re: ITSM Issue with Sandbox Enablement
I use cmdbdriver to generate new classes so that the class guids are what I want them to be. _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: 28 January 2009 21:46 To: arslist@ARSLIST.ORG Subject: FW: ITSM Issue with Sandbox Enablement 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
Re: ITSM Issue with Sandbox Enablement - Cause Found - Work-around possible
Hi Guys, Just to report back. Turns out I was staring it in the face for too long. Very simple problem. There are 4 Active Links that do NOT use the by Id Push Fields and are instead hard coded for BMC.CORE:BMC_ComputerSystem. No wonder that the Sandbox Recon job had Defer NULLs on! The Sandbox won't work for most attributes in even OOTB classes. The fix is to replicate these four ALs, once for each class and include all fields except a few core fields much as these work now. There is a better fix because the workflow is convoluted at best and could be simplified. the ALs change a few fields with Set Fields including the dataset id, do the Push Fields the clean the dirty bit and do not save the record. The Push in turn fires more workflow (filters) resulting in a separate push with the filter mentioned below. The ALs in Q are: ASI:SHR:GenericSave_003_CreateModify_EnabledSandBox_NothingInSandbox ASI:SHR:GenericSave_003_CreateModify_EnabledSandBox_SomethingInSandbox ASI:SHR:GenericSave_003_Dialog_EnabledSandBox_NothingInSandbox ASI:SHR:GenericSave_003_Dialog_EnabledSandBox_SomethingInSandbox I will automate the generation of the ALs so that when fields and classes change, the ALs can be maintained. Besides, it would be too much form to map 400+ fields for each of the classes in 4 different ALs the ALs with To make the set of ALs Note the SandBox Enabled enum values in AST:AppSettings (0: Yes, 1: No) and those in the AST z1G SandBox Enabled (10: Yes, 20: No). That was fixed with another AL. Note too that Defer NULLs should NOT be on in the Sandbox Recon job. So indeed, the Sandbox has been problematic, and, of course, there's also the Q of why the Sandbox is there in the first place! Enjoy the weekend. Ben www.softwaretoolhouse.com _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of P Romain ARSlist Sent: January 29, 2009 10:42 AM To: arslist@ARSLIST.ORG Subject: Re: ITSM Issue with Sandbox Enablement ** I use cmdbdriver to generate new classes so that the class guids are what I want them to be. _ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: 28 January 2009 21:46 To: arslist@ARSLIST.ORG Subject: FW: ITSM Issue with Sandbox Enablement 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
Re: ITSM Issue with Sandbox Enablement - Cause Found - Work-around possible
Thanks for the thorough update Looks like the sandbox was not properly QA'ed !! I'd like to see the test cases the QA tester used on the sandbox. This feature is touted a great deal by BMC sales, so you would think with all the exposure and fanfare, it would be solid and ready for prime time. yeah right -Guillaume From: Action Request System discussion list(ARSList) on behalf of Ben Chernys Sent: Thu 01/29/09 3:38 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM Issue with Sandbox Enablement - Cause Found - Work-around possible ** ? Hi Guys, Just to report back. Turns out I was staring it in the face for too long. Very simple problem. There are 4 Active Links that do NOT use the by Id Push Fields and are instead hard coded for BMC.CORE:BMC_ComputerSystem. No wonder that the Sandbox Recon job had Defer NULLs on! The Sandbox won't work for most attributes in even OOTB classes. The fix is to replicate these four ALs, once for each class and include all fields except a few core fields much as these work now. There is a better fix because the workflow is convoluted at best and could be simplified. the ALs change a few fields with Set Fields including the dataset id, do the Push Fields the clean the dirty bit and do not save the record. The Push in turn fires more workflow (filters) resulting in a separate push with the filter mentioned below. The ALs in Q are: ASI:SHR:GenericSave_003_CreateModify_EnabledSandBox_NothingInSandbox ASI:SHR:GenericSave_003_CreateModify_EnabledSandBox_SomethingInSandbox ASI:SHR:GenericSave_003_Dialog_EnabledSandBox_NothingInSandbox ASI:SHR:GenericSave_003_Dialog_EnabledSandBox_SomethingInSandbox I will automate the generation of the ALs so that when fields and classes change, the ALs can be maintained. Besides, it would be too much form to map 400+ fields for each of the classes in 4 different ALs the ALs with To make the set of ALs Note the SandBox Enabled enum values in AST:AppSettings (0: Yes, 1: No) and those in the AST z1G SandBox Enabled (10: Yes, 20: No). That was fixed with another AL. Note too that Defer NULLs should NOT be on in the Sandbox Recon job. So indeed, the Sandbox has been problematic, and, of course, there's also the Q of why the Sandbox is there in the first place! Enjoy the weekend. Ben www.softwaretoolhouse.com From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of P Romain ARSlist Sent: January 29, 2009 10:42 AM To: arslist@ARSLIST.ORG Subject: Re: ITSM Issue with Sandbox Enablement ** I use cmdbdriver to generate new classes so that the class guids are what I want them to be. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: 28 January 2009 21:46 To: arslist@ARSLIST.ORG Subject: FW: ITSM Issue with Sandbox Enablement 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
FW: ITSM Issue with Sandbox Enablement
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. http://www.softwaretoolhouse.com/_logs/ARUSERC2.ZIP 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 mailto:ben.cher...@softwaretoolhouse.com Web: http://www.softwaretoolhouse.com/ http://www.softwaretoolhouse.com A free notepad for Diary fields: http://www.softwaretoolhouse.com/downloads/DiaryFieldEditor.htm 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 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 idpush 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%' 001002 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%' 001002 SQL row: 1 Col 0: ASI:SHR:SandboxCallReconEngine_999 Col 1: 1\4\1\99
Re: ITSM Issue with Sandbox Enablement
In my last position we struggled and fought with the Sandbox for quite a while, finding issues here and there, and finally came to the conclusion that the Sandbox provides no real value as it is currently implemented (at least ITSM pre-7.5, I haven’t see how they’ve changed it there yet), is fatally flawed in a few different ways and just caused more headaches than it was worth. In the end, we decided to simply turn it off, and I would recommend the same unless you have a specific need for it. In my opinion, the only real and valid benefit that could be obtained from a Sandbox would be as a staging area to make changes that are to be applied to the Gold dataset at a later time. The Sandbox implemented in CMDB 2.1 and earlier does not work this way. It is merely a pass-through dataset that gets immediately reconciled into Gold. As such, I see no benefit in using it. You could argue that it gives you the ability to limit what kinds of changes a person can make to Gold by changing the reconciliation rules. However, I would argue that if you don’t want someone to change something, because you have a better (automated) source for the information, a more appropriate solution would be to simply not let them change it in the first place via an active link or something that makes the field read only. It is extremely poor user interaction design to let someone make a change and save it, only to wonder why it didn’t take effect afterward. I know this isn’t what you were looking for, but after everything I went through trying to correctly use the Sandbox, I would recommend to just about anyone to leave it be and turn it off until its design and implementation get fixed. Good luck, Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: Wednesday, January 28, 2009 2:26 AM To: arslist@ARSLIST.ORG Subject: FW: ITSM Issue with Sandbox Enablement ** 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.ZIPhttp://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.comhttp://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 idpush 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
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 From: Action Request System discussion list(ARSList) on behalf of Lyle Taylor Sent: Wed 01/28/09 2:52 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM Issue with Sandbox Enablement In my last position we struggled and fought with the Sandbox for quite a while, finding issues here and there, and finally came to the conclusion that the Sandbox provides no real value as it is currently implemented (at least ITSM pre-7.5, I haven't see how they've changed it there yet), is fatally flawed in a few different ways and just caused more headaches than it was worth. In the end, we decided to simply turn it off, and I would recommend the same unless you have a specific need for it. In my opinion, the only real and valid benefit that could be obtained from a Sandbox would be as a staging area to make changes that are to be applied to the Gold dataset at a later time. The Sandbox implemented in CMDB 2.1 and earlier does not work this way. It is merely a pass-through dataset that gets immediately reconciled into Gold. As such, I see no benefit in using it. You could argue that it gives you the ability to limit what kinds of changes a person can make to Gold by changing the reconciliation rules. However, I would argue that if you don't want someone to change something, because you have a better (automated) source for the information, a more appropriate solution would be to simply not let them change it in the first place via an active link or something that makes the field read only. It is extremely poor user interaction design to let someone make a change and save it, only to wonder why it didn't take effect afterward. I know this isn't what you were looking for, but after everything I went through trying to correctly use the Sandbox, I would recommend to just about anyone to leave it be and turn it off until its design and implementation get fixed. Good luck, Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: Wednesday, January 28, 2009 2:26 AM To: arslist@ARSLIST.ORG Subject: FW: ITSM Issue with Sandbox Enablement ** ? 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 http://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 mailto:ben.cher...@softwaretoolhouse.com Web: http://www.softwaretoolhouse.com http://www.softwaretoolhouse.com/ A free notepad for Diary fields: http://www.softwaretoolhouse.com/downloads/DiaryFieldEditor.htm 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 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
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 _ From: Action Request System discussion list(ARSList) on behalf of Lyle Taylor Sent: Wed 01/28/09 2:52 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM Issue with Sandbox Enablement In my last position we struggled and fought with the Sandbox for quite a while, finding issues here and there, and finally came to the conclusion that the Sandbox provides no real value as it is currently implemented (at least ITSM pre-7.5, I haven’t see how they’ve changed it there yet), is fatally flawed in a few different ways and just caused more headaches than it was worth. In the end, we decided to simply turn it off, and I would recommend the same unless you have a specific need for it. In my opinion, the only real and valid benefit that could be obtained from a Sandbox would be as a staging area to make changes that are to be applied to the Gold dataset at a later time. The Sandbox implemented in CMDB 2.1 and earlier does not work this way. It is merely a pass-through dataset that gets immediately reconciled into Gold. As such, I see no benefit in using it. You could argue that it gives you the ability to limit what kinds of changes a person can make to Gold by changing the reconciliation rules. However, I would argue that if you don’t want someone to change something, because you have a better (automated) source for the information, a more appropriate solution would be to simply not let them change it in the first place via an active link or something that makes the field read only. It is extremely poor user interaction design to let someone make a change and save it, only to wonder why it didn’t take effect afterward. I know this isn’t what you were looking for, but after everything I went through trying to correctly use the Sandbox, I would recommend to just about anyone to leave it be and turn it off until its design and implementation get fixed. Good luck, Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Ben Chernys Sent: Wednesday, January 28, 2009 2:26 AM To: arslist@ARSLIST.ORG Subject: FW: ITSM Issue with Sandbox Enablement ** 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. http://www.softwaretoolhouse.com/_logs/ARUSERC2.ZIP 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
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 From: Action Request System discussion list(ARSList) on behalf of Lyle Taylor Sent: Wed 01/28/09 2:52 PM To: arslist@ARSLIST.ORG Subject: Re: ITSM Issue with Sandbox Enablement In my last position we struggled and fought with the Sandbox for quite a while, finding issues here and there, and finally came to the conclusion that the Sandbox provides no real value as it is currently implemented (at least ITSM pre-7.5, I haven’t see how they’ve changed it there yet), is fatally flawed in a few different ways and just caused more headaches than it was worth. In the end, we decided to simply turn it off, and I would recommend the same unless you have a specific need for it. In my opinion, the only real and valid benefit that could be obtained from a Sandbox would be as a staging area to make changes that are to be applied to the Gold dataset at a later time. The Sandbox implemented in CMDB 2.1 and earlier does not work this way. It is merely a pass-through dataset that gets
FW: ITSM Issue with Sandbox Enablement
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
