DemoSim Admin

Demo Admin is an integrated development environment (IDE) for creating and editing scenarios, as well as configurations for customizing those scenarios to individual use cases.

Demo Admin is hosted at https://bpSalesEngineering.com as part of a larger strategy to serve BigPanda Sales Engineering utilities via a SaaS platform. Earlier in BigPanda's growth, DemoSim was only used by Sales Engineering for the purpose of New Business Meeting (NBM) demonstrations, but it soon took on a life of its own, being used in Proof of Value (POV) engagements to replay customer alert and change data and even used by Customer Success (CS) and Enablement to help employees (and even customers) learn BigPanda. Even our Marketing department uses DemoSim to create videos and self-guided demonstrations!

A Demo Config is a set configuration that customizes how a DemoSim scenario is played out. It determines which BigPanda organization receives the scenario events, which integrations receive the alert or change events, what variables those events can use, and which scenarios are available for use.

When you first create a Demo Config, you are presented with the SETTINGS tab.

See the installation instructions for Create a New DemoSim Org to create a DemoSim Org.

The Demo Config Name is not the same thing as a BigPanda organization name. It is simply a name for this Demo configuration. There's no reason that you couldn't use the same name as your BigPanda organization, but you really should name it to indicate its purpose. For example, if this Demo Config's purpose is to demonstrate BigPanda to the Acme company, perhaps you would call the Org "Acme Inc NBM Demo". Don't worry about creating a lot of these orgs; they're easy to create, clone, and delete. Also, the Demo Config Selector dialog will filter as you type, so with a few characters its pretty easy to find the config you're looking for. BTW, the DemoSim extension uses this same Demo Config Selector.

The Demo Config is tied to a specific BigPanda organization via an API Key. When you change the API key, the BigPanda Org Name text box validates the API key by showing the associated BigPanda organization name. Changing the API key also changes the integration mapping.

Best Practice: Prefer cloning an Org to changing the API key

If you want to change the Demo Config to be directed to a different BigPanda organization, don't change the API Key; instead, clone the Org providing a new API Key (see below). Only change the API Key in-place if the new key belongs to the same BigPanda organization.

The SPOC (Single Point of Contact) Email field is there to help site administrators easily know who to contact regarding this configuration. For example, you may be creating the configuration for someone else (say, the Demo Config is owned by you but you want the other person to be the primary contact). In most cases, this would be you... but it's there just in case that's not the case... ;-)

The Demo Config Owners field is there so that you can share ownership of this Demo Config with someone else. For example, in a POV there may be more than one Sales Engineers using DemoSim to teach the customer how to configure BigPanda. In this case it is efficient for them to both use the same Demo Config (i.e. integration mappings, variables, and scenario choices).

bpSalesEngineering user account name format

BigPanda user accounts are authenticated by Okta; so your actual account name is your BigPanda email address prepended with "okta_". Demo Admin won't suggest or list other people's account names, nor will it reject an invalid name. So if you want to share your Demo Config with someone else, it's usually easiest to just ask the other person for their account name. You know you have it right if the other person can access your shared Org. :-)

Deleting a DemoSim Org will unlink any scenarios from the org and then remove its record. You'll first be prompted to verify that this is really what you want to do. There is no way to export or import Demo Configs, so make sure this is really what you want to do.

Demo Config scenario events are mapped to an integration type. For alert events, this implies a few things:

You have to decide between changing the scenario type's primary and secondary tag mapping or the tags used in the scenario. If you change it in the integration type, all scenarios (in this Demo Config) that use this type must have those tags and they must contain the correct data. This makes scenario sharing difficult (even simply reusing your own scenarios) if you don't stick to a standard set of primary/secondary tags for a given integration type. When we get to scenario development, later, we'll show you how to rename tags to conform to your chosen integration type preferences.

Best Practice: DemoSim alert and change events are intended for REST integrations

Note that you can map DemoSim integrations to both REST and Out-of-box integrations. However, it's up to you to know whether your target integration expects a flat object or a complex object structure. DemoSim will send flat object payloads (JSON), so some Out-of-box integrations cannot be used. Same with change integrations; choose REST unless you really know that the target integration can handle a flat payload.

The Integration Type editors provide information and choice for several aspects. Let's look at two examples, both with an integration named "AppDynamics" but one as a generic REST integration and the other as the OOTB AppDynamics integration:

The API Type and Default Tags fields show what type of integration the choice is. This is a good example of the complicated schema required for an OOTB integration versus the simple schema of a REST integration. Again, you can choose either but "your mileage may vary"!

Another thing to note is that the default primary and secondary tags for a REST integration are "host" and "check", respectively. This is why (as you'll see later in the discussion about the scenario alert event schema) primary and secondary property mapping is part of the integration mapping for each DemoSim Org configuration.

DemoSim scenarios use variables with a curly-brace format like so: ${rnd.app_code.s1}

The seed value is used to repeat the value within the scenario. Each time the scenario is played, a random value is chosen from among the values you've populated in the DemoSim Admin Variables tab; however, that value is reused everywhere else that the code is found (that is, every alert and change event in the scenario). When the scenario is played again, a new random value is chosen and used for that seed. On the other hand, if you want randomization within the scenario, just don't use seeds.

There are 10 standard variable codes:

For anything else, you can use the variable classes: ip_octet, aws_id, a (alpha), d (digit), or h (hex).

This is done so that you can have internal consistency within the scenario. For example, in the first scenario that you created when you followed the integration instructions, the alert event's host tag is ${rnd.aws_id.s1}.${rnd.geo_code.s1}.${rnd.urldomain.s1}. This code is also used in the change event's summary and instance tags. This is why you get correlation of your one change event to your one alert event, out of box; you get the same hostname showing in all three tags. The next time you run the scenario it will be a different hostname, but will still be consistent among the three tags.

This gives a lot of flexibility for creating standard scenarios where, even though the details change, the story is the same.

The DemoSim Scenario is a distinct record in the DemoSim API that includes event and change records as well as some other metadata for identification and sharing. When the DemoSim Chrome Extension plays the scenario, changes are sent first and then alerts. Alerts are sent in batches, according to the individual integration type's App Key; so if the scenario has 5 "infra-mon" alerts and 8 "app-mon" alerts then you see two status messages saying that DemoSim posted 5 alerts and 8 alerts, respectively.

If the alert events include PAUSE records then the scenario is considered a multi-step scenario; that is, you can send the scenario alerts to BigPanda in stages.

Scenario Alert Timeline, Offsets, and Pauses

When you trigger the DemoSim Chrome Extension to start a scenario, DemoSim calculates all of the alert timestamps relative to the time that you clicked the mouse. So if the largest offset is 1800 seconds then the first scenario alert will have started 30 minutes before. This is done to keep the timing of the events consistent, regardless of how long you may pause in a multi-step scenario.

Let's say that you have a scenario with 5 alerts, followed by a pause, and then followed by another 8 alerts. Let's also say that the last event's offset is 300 seconds (five minutes). So if you were to play the entire scenario without a pause, in the BigPanda timeline it would show that the incident lasted 5 minutes. If you start the scenario and let that pause last for 15 minutes (while you explain the glories of BigPanda...), then you resume the scenario to play the last 8 alerts:

If you said it started 20 minutes ago and ended 15 minutes ago, you're right!

That's because all the offsets were calculated when you clicked the mouse, regardless of how many pauses or how long you pause.

If you need to play out several scenarios (for example, to create a "background" list of incidents") simply split your events into several scenarios. DemoSim Chrome Extension plays the scenarios asynchronously, so you don't have to wait for one scenario to finish before sending another. Click them all as fast as you can and leave the extension interface open to see the status (at the bottom); you'll see the feedback from all the scenarios play back. In that respect, the only limit is BigPanda's API throttle limits.

Playing large scenarios

If you need to post a large number of alert events, use the Sales Engineering SWAT utility called bpInjector

If you need to post a large number of change records, use bpChangePoster

The following tables show the schema for the Events and Changes.

For the Events schema, the following table shows the required fields. All other fields (last row) are alert tags that you are free to define as you wish. Note that the "status" tag is part of BigPanda Alerts api metadata but not the DemoSim Event schema metadata; this is why it's a tag for DemoSim.

For the Changes schema, the following table shows the required fields. All other fields (last row) belong to the tags array.

Calculating change record start and end times

The change record start and end timestamps are calculated using the "_offset" field relative to the start and end of the scenario.

So in this way, DemoSim ensures that the change record "wraps" the alert incident time window.

Your Demo Config's SCENARIOS tab lists the scenarios that you've added to the Org. Each scenario is presented in a collapsible Scenario Editor. When a Scenario Editor is collapsed, all you see is the scenario name on the left and an icon that points downward on the right. Clicking the scenario name will expand or collapse the Scenario Editor. Collapsing a Scenario Editor removes its data from your browser's memory; uncollapsing it will pull the data from the cloud and load into your browser. Depending on the size of your scenario, this can be up to about 1/2 Mb. There's really no limit to how many scenarios you can have in your Org but uncollapsing all of your Scenario Editors will definitely chew up RAM.

When a Scenario Editor is expanded, you will see a series of buttons on the top:

Below the buttons are the scenario name, description, and background fields. After that are the fields for scenario sharing:

The rest of the Scenario Editor contains the Events and Changes grid editors. A "Grid Editor" is a sort of "spreadsheet lite", allowing you to

[block:image] { "images": [ { "image": [ "https://files.readme.io/c098890-Screen_Shot_2022-03-15_at_11.06.07_AM.png", "Screen Shot 2022-03-15 at 11.06.07 AM.png", 2266 ], "caption": "The Scenario Tester" } ] } [/block]

DemoSim scenarios are stored and shared through the Scenario Store. When you create a scenario, it is stored for you to use in any of your Demo Config configurations. You can also find scenarios that other people have shared. The quickest way to find a scenario is to use the Search dialog and search through the scenario names, descriptions, or owners. When you find a scenario that you want to add to your Org, simply click in the checkmark box and press SUBMIT.

There are three ways to create a new scenario:

To remove a scenario from your Org, uncheck the scenario from the Scenario Store (or, from the Scenario Editor, click the REMOVE button.) To delete a scenario that you own, from the Scenario Editor simply select the DELETE SCENARIO button.

Deleting Shared Scenarios

Before you can delete a scenario, you must un-share it. Even when you've un-shared a scenario, you still need to wait until all other users are no longer using it in their own ORGs before you can delete it. You can see who is using your scenario in the Scenario Users list (in the Scenario Editor).

Demo Admin will automatically remove a shared scenario (from your ORG) for which you no longer have access. When you select an ORG that is using that scenario, you'll see a pop-up alert saying that the scenario has been removed from your Org.

So the trick to deleting a shared scenario is to first un-share it, then wait for the Scenario Users list to empty. Alternatively, you can contact [email protected] and ask for the scenario to be forcibly removed, but this should be considered a last resort.

As you can see, deleting a shared scenario is a bit of a pain. It's better to edit your shared scenario than to delete it, as people probably depend on it being there for them to use.