Paul, If the passwords of test and prod can be the same, you might be interested in our approach: - on remedy prod server, create an alias to production web service in the /etc/hosts file - on remedy test server, create the same alias to test web service in the /etc/hosts file In filters, use the alias as endpoints, so you can just migrate the filters from test to prod.
Best regards, Jean-Louis Halleux ARSmarts s.a. On 13 Jun 2013, at 17:57, "Longwing, Lj" <[email protected]> wrote: > ** > Paul, > when faced with the EXACT same scenario a few jobs ago, we opted for a > 'copies' approach, but instead of $SERVER$, we did a lookup on a form for > which environment THIS server should be running against 'this run', then the > filter fired for that environment (allowed for dynamic pointing of dev to qa, > qa to prod, etc, usefull for reproducing prod issues in dev and such)...but > it was the most effective manner we found. > > I'm told (but haven't tested) that the Atrium Web Services Registry allows > for this type of dynamic changing of things...but if you are completely > custom, with no ITSM in house...then you don't have that infrastructure. > > For what it's worth, to make our copies we exported to XML Def, made the > changes to the filter name/other properties, imported new copy, using same > def, made additional changes for additional environment, import, repeat as > necessary. > > in our environment we had 10 servers that needed copies, and about 30ish > places we called web services...so yes...that's allot of workflow, but in the > end it was the most flexible solution that worked extremely well for us. > > > On Thu, Jun 13, 2013 at 9:49 AM, Campbell, Paul (Paul) <[email protected]> wrote: > ** > This is going to be a bit wordy, so hang with me > > > > My custom Remedy environment integrates with an Oracle Fusion Middle Ware > server to perform Web Service operations for a third Party app (Siebel) and > the filters we build have the user, password, and end points imbedded in the > filter actions, so that when me move the filters from our test environment to > production, we have to edit the end points and passwords (the usernames are > the same, but the passwords are different between test and production.). The > way me make this change now is either edit the def file in XML format (a > remedy def would be way too hard because of line breaks) and manually change > the endpoint (we can look this up from a control record now) and change the > encrypted password, or we make two copies of the filter, one with Test values > and one with production values and use $SERVER$ LIKE “q%” for test or > $SERVER$ LIKE “p%” for prod. We have 50 or more filters with Web Service > actions, so this gets unruly really quick. The authentication for the Oracle > FMW is basic endpoint authentication using the user and password you used to > load the WSDL from the FMW URL (using the login button on the web service > action), no WSS authentication, etc. > > > > My question is, does anyone know of an easier way to make these changes other > than opening up the XML formatted Def in a text editor or duplicate filters? > I’ve tried awk and regex statements, but it just seems a little too hokey for > me. I’m even ok with writing a java app that reads the def file, modifying > the data and re-writing the def, granted I’m looking for a little easier way > than that. > > > > My ultimate goal would be to use the Object Modification Log to produce my > defs for source control and make my migration packages from there, but the > object Modification log only stores remedy defs, not XML. > > > > Paul Campbell | Development Team Lead | TS&D SSBL, A2R WFE, and ESP Remedy > Team | Avaya Client Services | > > | 1145 Sanctuary Parkway Lake View II Suite 110 Alpharetta, GA 30009 | > 678-421-5342 > > > > _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"
