Xoom Corpus Generator is the tool we use to capture a particular Service Optimization environment for playback on a different machine. This is most commonly used in order to demonstrate Xoom against that environment prior to Xoom being installed there (i.e. in pre-sales situations), to implement the support for any customisations that may exist on that system, and for troubleshooting.
For best results, please run Xoom Corpus Generator on a Service Optimization environment that sports a full diversity of configuration used by the customer. In other words, it doesn’t have to be the production environment and it doesn’t have to contain every instance of every object, but it should contain all different kinds of settings and objects that are in use.
The tool can be obtained on request, and is usually distributed as a 7-zip file. You just unzip the tool anywhere on the chosen Service Optimization server and run it from there from the command line. The corpus can be generated inside the tool’s folder. For example, from the command line you can change to the tool folder and then run:
The tool will ask you for credentials to connect to Service Optimization, and then it will create a XoomCorpus folder right there that you can then inspect (if you wish), zip and send over. We recommend the use of 7-zip with file encryption to avoid any mail filters. You can also put the file somewhere online for us to download. We’ll then use the corpus for the demo and later to create a custom installer.
This approach has the following benefits for the customer, in particular from the point of view of infrastructure security and data protection:
- we (Zany Ants) don’t need to install anything on the customer machine, as the tool is stand-alone and only needs to be run once;
- we don’t need access to the customer environment, as the tool can be run by the customer without any specialist knowledge;
- we don’t need access to the Service Optimization database;
- in vast majority of cases we don’t get access to any of the transactional data (engineers and tasks in particular, as they would be the most sensitive – these are explicitly excluded).
For us, the benefits are more practical:
- it allows us to pretend (for the purposes of working with Xoom) that we are in the customer environment without actually needing to access it;
- there is no need to transfer huge amount of data (Xoom corpora sizes, once zipped, are measured in a small number of megabytes, and not gigabytes as full database dumps may be);
- we don’t have to install the right version of Service Optimization, with all the customer’s customisations. In fact, we can use the corpus on a machine entirely without Service Optimization on it, as long as we have Xoom.
When run, the tool will capture the following information about the customer’s Service Optimization environment on which it is run:
- the full scheme information;
- all rules, objectives, metrics, groups, relevance groups, reports, settings and administrative user settings (templates);
- all dictionaries (product and custom);
- all cached custom business objects; and
- Service Optimization file signatures (but not the file contents themselves) and version information.
While it is typically possible to identify the customer from the corpus (in particular if the settings contain project information), we rarely capture any personal information that would be subject to data protection, and even when we do it would be very unlikely for us to actually access it or even know it was there. Regarding general data security, as a rule we have an NDA in place, and we never share any Xoom corpora with any external entities that are not directly involved with the project and hence already have direct access to that Service Optimization environment.