Amol,
Thanks for your response. I do have a support ticket created actually ISS04180124, assigned to Ritu. She updated that ticket yesterday (much after your email seems to have come in) stating that she has yet to try it in-house, so if there is a way for you to contact her, and let her know of your findings, it might save her/BMC some time. I had not checked my email since yesterday, so missed both emails until now. I suspected it was a miss as it usually is only recompiled with new supporting dll's with a new version unless there is a major version that is released that has a new field type or a new action type. Thanks for your email. Appreciate it. I guess for those who use this utility during their development - you might want to check your Set Field filters that use WSDL, in the event you have changed the ID's of fields used in that set field action. They would not have got changed.. Joe _____ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Dixit, Amol Sent: Tuesday, September 03, 2013 12:46 AM To: arslist@ARSLIST.ORG Subject: Re: Bug in archgid?? Could has anyone else encountered this?? Joe, I found that the scenario you explained here is not working in any version of 'archgid' utility. Which means it is a total miss-out. Please create a support ticket for the same and BMC will fix it for you. Amol From: Joe D'Souza [mailto:jdso...@shyle.net] Sent: 22 August 2013 00:35 Subject: Re: Bug in archgid?? Could has anyone else encountered this?? ** This is development on base mode as we are working on a 100% home grown system at the moment. The form the filter is firing on is home grown in base mode many versions before 7.6.4. The current development effort on that app is all in the base mode as well. The field references were changed in AL's on those fields, and filters on those fields if the filter was not using those fields in a Set Field operation using WSDL as transaction type. Its just not changed in the field mappings of the WSDL. The more I think about it, the more I think it's a bug and a oversight in the design of the archgid. Joe _____ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, August 21, 2013 2:04 PM To: arslist@ARSLIST.ORG Subject: Re: Bug in archgid?? Could has anyone else encountered this?? Sorry . I thought hosting a web service and mapping to fields, not consuming and mapping to fields. (That is what I get for trying to switch to decaf) I wonder if it is an issue with Overlays and archgid. My experience on 7.6.4 with all custom pure base mode was it worked (even in filter plugin mappings). Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Wednesday, August 21, 2013 12:56 PM To: arslist@ARSLIST.ORG Subject: Re: Bug in archgid?? Could has anyone else encountered this?? ** Fred, Thanks for your response.. This has nothing to do with the Mid-tier cache. Maybe I was not quite that clear when explaining the issue and what exactly I had done / was doing. I have a filter where I was consuming an external WSDL, and I had my input and output mappings. I had to change some of the field ID's for the purpose of organization from let say 800101600 to 800101300 on lets say a field called $Start Date$. In the filter mapping before the change everything looks nice - as in the element startDate mapped to $Start Date$. Post archgid, the mapping looked like startDate to <800,101,600> indicating that in the filter definitions itself, the ID was not changed although the archgid reported that it "successfully updated field ID's in filter definitions". Flushing the Mid-Tier cache would be applicable if it was a WSDL I was publishing and had made changes to it. While consuming a WSDL using a Filter, the Mid-Tier does not even come into the picture - its just the AR Server WSDL Plugin that is used and all the filter definitions are stored in the database. This is why it appears to be a bug with the archgid where it appears like it does not actually change the ID's of the fields that are mapped in the Set Fields actions of a Filter. Before reporting this bug to BMC, I wanted to see if anyone else has experienced this on other versions. I am on AR Server 7.6.04 Patch 003. Joe _____ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W Sent: Wednesday, August 21, 2013 9:20 AM To: arslist@ARSLIST.ORG Subject: Re: Bug in archgid?? Could has anyone else encountered this?? Did you flush the Mid-Tier cache? Fred From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Tuesday, August 20, 2013 8:36 PM To: arslist@ARSLIST.ORG Subject: Bug in archgid?? Could has anyone else encountered this?? ** I used archgid to change the field ID's of a few fields that were used in the Set Fields mapping of Filters that called a WSDL to set some fields. I noticed that although archgid ran with no errors claiming to have succesfully updated field ID's in filter definitions, none of the mappings were updated with the new field ID's in those filters that had that WSDL call using these fields mapped to its inputs. Is this an oversight by or just 'working as designed' as far as the archgid is concerned? I recall reading exceptions such as ID's contained in macros, or Direct SQLs would not get modified using archgid but do not recall the same exception to have been made with the Set Fields mappings for actions using WSDL to set fields. Has anyone else noticed this and reported this to BMC Support? Joe _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
