Absent Member.. MTWalsh Absent Member..
Absent Member..

SAI Usage

I just wanted to throw this topic out there for discussion amongst all you experts.  Have any of you used only a custom SAI to manage software application data in DDMI...no master SAI? 


My thought on this is, why bring all that extraneous data over in to Asset Manager?  Each company probably only cares about setting up counters for a fairly limited number of software titles (as opposed to the 17k+ in the master SAI).  And since one of the big issues we face a lot of times is dealing with the volume of data going from DDMI to AM, why not limit it at the source by only using a custom SAI. 


I've seen people try to control the volume by limiting it via pre-queries and such from CIT (i.e. only bring over stuff that has been mapped to a counter), but I haven't seen, nor tried myself (other than in my current dev environment) to manage totally at the SAI level.  Is this something any of you do?  Can you think of any drawbacks besides the obvious ones (i.e. having to spend time making updating your custom SAI each time a new one is released from HP instead of just importing the new master and also needing a bit longer lead time to do a counter in AM).

4 Replies
Jeff Sikorski Absent Member.
Absent Member.

Re: SAI Usage

I gave that some serious thought once upon a time... but then I realized that I just wouldn't have the time.


The big ones are such a pain and have so many different releases/versions... and they typically license you per version... so you are talking about a lot of work.




If you decide to 'copy over' MAster SAI footprints into your user Library for that... you'd have to be careful on a monthly basis.  Whenever HP makes footprint adjustments, you'd have to copy it over, etc.


What i would suggest you do is attack it from the Connect-It scenario route:
Go into DDMI, find every app that you want to bring over

Go into Connect-It, and set up filters to only get those apps


seems like a win-win 🙂



Absent Member.. MTWalsh Absent Member..
Absent Member..

Re: SAI Usage



I was kind of more thinking about doing it on a publisher basis mostly.  It doesn't seem like it would be that much effort to once a month copy the few publishers that we (certainly at least initially) intend to manage in AM.  But yeah, if i did it at the application level it would be a pain. 


I've tried various things at the CIT level too, though I hadn't really thought of setting it up as a filtered query like that since we'd have to modify the CIT scenario each time the list changed, and to me, that seems more complex for them to continue to do after I left....but I suppose that could be done at the publisher level as well, which would make it a little more managable there too..





Micro Focus Expert
Micro Focus Expert

Re: SAI Usage

Good points raised by Jeff. What I would also add:

- Risk with the data accuracy (unless you import the HP data every month/when something changes)

- Related to above, you have to make sure you properly set the dependencies when you have the suites of apps, so licenses are counted properly

- If you decide not to include the Master SAI, you will have a huge number of unrecognized files. It will be very hard to identify your missing apps and improve your recognition when you don't know if the unrecognized files are coming from the Master SAI list or your custom list.




Absent Member.. MTWalsh Absent Member..
Absent Member..

Re: SAI Usage

That's sort of the whole point Brindusa.  I want to avoid managing it as if we for some reason needed to include every title in the world in there.  On the AM SAM side, for any of the SAI information to have any value, someone has to set up counters.  When they do this, they tend to want to focus on particular vendors.  For example, Oracle is a big one these days.  If all the business cares about tracking is Oracle titles, why not manage that from the SAI instead of trying to manage it from within AM.  We all know how difficult it can be to performance tune CIT scenarios in order to bring all that software data over in to AM.  In fact, that is the biggest selling point to me of using an SAI to track software to begin with...reducing the amount of data that we are moving around and that the end users have to parse through to build counters (besides of course the added accuracy of SAI based recognition).


In this model, you would never need to do a "recognition" project like what is outlined in the scan file analysis guide, at least not beyond trying to get all of the titles for the particular vendors that the business cares about tracking. I know this seems a little reactive, but when the alternative is hundreds of thousands of un-necessary records in Asset Manager.....well.....to me it's worth that tradeoff I think.  I guess this wouldn't maybe work so well in an environment where the DDMI folks don't have regular contact with the AM folks.  That would be something to think about.  I'm not really suggesting though that I would want to do it this way for every client.  I don't see it as necessary for smaller environments where there are only say, 20k or less scanned computers.  When we get up around 40 or 50k scanned computers though, I think it starts to become a little more necessary to try and limit the data coming in to AM.


Also, when you copy a publisher from one SAI to another, you have the option of bringing over all of the titles under that publisher and all of the dependancy and license info as well....just have to hold down control when you drag the publisher from the master SAI to your user SAI.   I've done it in our dev environment and it shows all of the Publishers, files, package rules, license relations, etc that were associated to the publishers I was copying over.  Took me like an hour to copy half a dozen publishers in to my custom SAI and publish the SAI.  What i'm thinking is that each month when the new master comes out, i'd need to update my user SAI by recopying each publisher we are tracking over to my custom user SAI.  So that would be an added task when updating the SAI's monthly.  But not that big of one really.


I'm not totally sure I follow your third point, that it will be difficult to know if the unrecognized files are coming from the master or user sai list.  I think what you are saying here is that we wouldn't know if maybe those unrecognized files would be recognized under the master SAI if we aren't using the master in the xml enricher right?  If so, then I agree, it might be kind of hard to see that easily, though you certainly could maintain a dev environment where you did use the master SAI and deal with it that way, or deal with it by loading the master when you go in to the Analysis Workbench. 


The biggest drawback I can think of so far is needing a little more lead time when the AM folks want to start tracking a new publisher.  We'd have to add it to the custom SAI (by copying it from the latest master) and then reprocess all of our scan files.  So I'm thinking about 2-3 days of lead time from when they notify me they need a new publisher to when I can change the SAI and then get all the scan files run back through (cut and paste them from processed to incoming...maybe not all at once :).....  But i'm also thinking, that this won't happen all that often, especially after the inital ramp up period when they are figuring out which vendors they want to track.  And then of course, there is all the regular work of them reviewing the data and pointing out any missing titles and then doing some analysis on the DDMI side to get those titles in before we can write done to the counter creation effort of course. 


I think where I may end up on this is, try it first with the master and if I run in to issues where the CIT scenarios are taking forever, throw this out there as an option, if and only if there is good communication between the DDMI and AM teams...or a good possibility of establishing good communications at least.  That is, assuming someone doesn't pipe in with a deal breaker on it that we haven't thought of yet 🙂

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.