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 Platform Sparc Sun Fire V240 OS Solaris 5.10 DB Oracle 10g2 ARS 7.1 patch 5 ITSM 7.0.3 patch 7 Cheers Ben Chernys
Senior Software Architect Software Tool House Inc. Canada / Deutschland / Germany Mobile: +49 171 380 2329 GMT + 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 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\1000000076\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: ASI:SHR:SandboxCallReconEngine_999 Col 1: 1\4\1\99\400127400\99\1714700\4\1\99\301774800\2\4\9\Reconclie\ <-------------------->SQL row: 2 Col 0: ASI:ALK:CheckQty_450 Col 1: 1\1\2\4\5\99\301149300\2\2\0\4\1\99\301149300\2\0\4\6\99\301774800\2\4\9\Reconclie\4\6\50\200000020\2\4\13\SandboxCreate\ Have you seen this behaviour? And can you recommend anything to get around this? This is a show-stopper for us for now. Cheers Ben Chernys <<ARUSERC2.ZIP>> . _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: RMI Solutions ARSlist: "Where the Answers Are"
