It's a shame that the workflow checking the incoming CI against the product catalog doesn't check using the product and manufacturer aliases. The only alias it uses is the alias mapping form.
7.5 is, in a way, worse as the normalisation engine uses its own alias form for products and manufacturers. You might therefore be maintaining aliases in two places. I would agree that you don't have to use BMC DSL. It is not so easy to use the custom DSL import forms. If all you need is the the data in the PCT:Product Catalog form and don't need model/version, patch or file info then I'd just import the data directly to this main form. > I don't think you would be violating some unwritten rule by ditching BMC's > DSL data. At my last position, we didn't use any of it either. We > created products on an as needed basis. > > That said, you can add aliases for products. So, you would decide what > the "standard" name of the product is going to be (that is, what you want > people to see in the system), and then you can add as many aliases as you > want. Then, when you discover a product on someone's machine, you look it > up using the alias. If you took that route, then you could keep BMC's DSL > data and simply add aliases that match what you're discovering. So, in > your case, you would simply add the alias of "Microsoft Office Project > Professional 2007" to the product "Microsoft Project Professional 2007" > that comes with the DSL. > > I'm not sure about your idea about using the Model/Version form to track > your products. Normally, that's really just for tracking versions of > products, patches, etc. The product name is really part of the product > category and not the version. You can create your own data if you want, > but, if it were me, I would stick with doing it consistent with how the > system was intended to be used. > > Lyle > > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Pierson, Shawn > Sent: Wednesday, August 26, 2009 8:57 AM > To: [email protected] > Subject: Importing Custom Titles into the DSL > > ** > Good morning, > > I'm working on an integration between LANDesk and Asset Management, and > while it's fairly straight forward, there is one area that is an issue. > I'd like to be able to automatically set the Product categories (aka the > CTIs) with the correct values by tying the suitename in LANDesk to the > Product Name field on PCT:Product Model/Version. The reason for this as > opposed to PCT:Product Catalog is because the names are most similar > there. > > However there is an issue. For example, the LANDesk field is "Microsoft > Office Project Professional 2007", while the BMC DSL version is "Microsoft > Project Professional 2007". This is an issue because BMC's version > doesn't have the word "Office" inserted in the title. LANDesk gets its > data from the same place that the Add/Remove Programs on Windows gets that > information. I believe this to be more correct. > > So to get to the end of my long story, what I'm considering is ditching > 100% of the data that BMC provides, and building in a feed from LANDesk's > AppSoftwareSuites table to populate the DSL using the BMC provided > document with the same title as the subject of this email as a guide. I > know that technologically, it can be done. > > My question is, is this ok? Will I be violating some unwritten rule by > ditching BMC's DSL data and going it alone? What are the risks? I can't > really see a downside in this case but wanted to get feedback from the > list before I proceed. > > Thanks, > > Shawn Pierson > Remedy Developer | Southern Union > > > Private and confidential as detailed > here<http://www.sug.com/disclaimers/default.htm#Mail>. If you cannot > access hyperlink, please e-mail sender. > _Platinum Sponsor: [email protected] ARSlist: "Where the Answers > Are"_ > > > 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 of the original message. > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:[email protected] ARSlist: "Where the Answers Are"
