Provisioning Simulation Example

An in-depth walkthrough of how one might use the simulations endpoint.

The Simulation feature is a great way for you to do integration testing as close as possible to production, but without affecting real customers and orders.

This guide will give useful examples that can help you make the simulator model real scenarios. With that established you can build a testing plan, and expand the scenarios that you are exercising your integration.

Simulation Feature Philosophy

Invoking a simulated order, and then seeing how your system reacts is one of the key ways of seeing if the provisioning integration is working.

The endpoint features a “works out of the box” philosophy that should let you invoke a simulated with random values very quickly. This works great for an initial smoke test, but as you want to get into more realistic simulation scenarios, you’ll want to override the default random values with your own data, in order to fit into your testing environment.

What follows are some ideas for how you can use this simulation endpoint to work through the life cycle of a few partners turning on a subscription, modifying it, and then deprovisioning. Based on what you learn from this example, you should be able to continue using the simulation endpoint to exercise more events that you want your system to be able to handle such as:

  • A partner who already has an account, just tried to get a new account
  • A partner who is from the wrong region tried to order
  • A particular kind of customer tries to upgrade from trial to paid
  • And any other combinations of new ordering events + testing state you want.

Simulation Walkthrough

Here is a sample storyline and a walkthrough of how you could use the simulation feature to model it.

Here are the situations that we will be simulating

  1. Different partners buying new subscriptions
  2. Canceling a subscription (deprovisioning)
  3. Converting a trial to paid
  4. Updating a quantity for a subscription

These ID’s are randomly generated for illustration purposes. You will make your own test ID’s for use with the simulation endpoint.

Let Partner 1 ID = 331684ad-5ad7-431e-9811-476813670a77
Let Partner 1 Enrollment ID = 0f872e4a-51cb-4ceb-b33c-914292958475
Let Company 1M ID = 879812be-de5c-4c52-af49-dfb321f9bffc

Let Partner 2 ID = 2d73eb3c-e96f-497f-b3d1-fb2bcdcca517
Let Partner 2 Enrollment ID = 07ce5c77-9ecf-4e2b-9003-a7c75182c43e
Let Company 2M ID = f97da0ef-d374-4019-9369-5f8315aa6408

Let Product A ID = de533202-a97b-46ab-9476-32acb524393e
Let Product B ID = 9ac6ffaa-f58c-466a-a7d1-7d01f1787617

Partner 1 buys a new subscription to Product A for Company 1M

POST /provision-simulations/order-events

{
    "isSimulation": true,
    "provisionRequest": {
        "partnerId": "331684ad-5ad7-431e-9811-476813670a77",
        "partnerName": "Partner 1",
        "partnerDomain": "partner1.example.com",
        "partnerEnrollmentId": "0f872e4a-51cb-4ceb-b33c-914292958475",
        "companyId": "879812be-de5c-4c52-af49-dfb321f9bffc",
        "companyName": "Company 1M",
        "productId": "de533202-a97b-46ab-9476-32acb524393e",
        "productName": "Product A",
        "quantity": 1,
        "subscriptionId": "6129b9ef-1fc6-4379-8130-376463e88d71",
        "type": "NetNew"
    },
    "provisionDetail": {
        "details": {
            "exampleCustomerData1": "collectedAtCheckout",
            "key2": "value"
        }
    }
}

A new subscription ID is created in Pax8, define S1 id = 6129b9ef-1fc6-4379-8130-376463e88d71

Usually we do not know the value of subscription id until a NetNew subscription is created, but for purposes of simulation, we provide a value to be echo’d back to us.

Your system should see this value come in the ProvisionRequest, and record it in the appropriate systems so that you can react to further events for this subscription.

Partner 2 buys a new subscription to Product A for Company 2M

POST /provision-simulations/order-events

{
    "isSimulation": true,
    "provisionRequest": {
        "partnerId": "2d73eb3c-e96f-497f-b3d1-fb2bcdcca517",
        "partnerName": "Partner 2",
        "partnerDomain": "partner2.example.com",
        "partnerEnrollmentId": "07ce5c77-9ecf-4e2b-9003-a7c75182c43e",
        "companyId": "f97da0ef-d374-4019-9369-5f8315aa6408",
        "companyName": "Company 2M",
        "productId": "de533202-a97b-46ab-9476-32acb524393e",
        "productName": "Product A",
        "quantity": 1,
        "subscriptionId": "d7fd89e7-f90c-4141-9e5a-5d68dbd6f63d",
        "type": "NetNew"
    },
    "provisionDetail": {
        "details": {
            "exampleCustomerData1": "collectedAtCheckout",
            "key2": "value"
        }
    }
}

A new subscription ID is created in Pax8, define S2 id = d7fd89e7-f90c-4141-9e5a-5d68dbd6f63d

You should now be able to observe both S1 and S2 in your system, both for Product A, and there are two different partners and companies.

Partner 1 updates quantity for subscription 1

POST /provision-simulations/order-events

{
    "isSimulation": true,
    "provisionRequest": {
        "partnerId": "331684ad-5ad7-431e-9811-476813670a77",
        "partnerName": "Partner 1",
        "partnerDomain": "partner1.example.com",
        "partnerEnrollmentId": "0f872e4a-51cb-4ceb-b33c-914292958475",
        "companyId": "879812be-de5c-4c52-af49-dfb321f9bffc",
        "companyName": "Company 1M",
        "productId": "de533202-a97b-46ab-9476-32acb524393e",
        "productName": "Product A",
        "quantity": 5,
        "subscriptionId": "6129b9ef-1fc6-4379-8130-376463e88d71",
        "type": "Update"
    },
    "provisionDetail": {
        "details": {
            "exampleCustomerData1": "collectedAtCheckout",
            "key2": "value"
        }
    }
}

As a result of this order event, you should now see that the quantity in your system for subscription 6129b9ef-1fc6-4379-8130-376463e88d71 went from 1 to 5.

Partner 2 buys a new subscription to Product B for Company 2M

POST /provision-simulations/order-events

{
    "isSimulation": true,
    "provisionRequest": {
        "partnerId": "2d73eb3c-e96f-497f-b3d1-fb2bcdcca517",
        "partnerName": "Partner 2",
        "partnerDomain": "partner2.example.com",
        "partnerEnrollmentId": "07ce5c77-9ecf-4e2b-9003-a7c75182c43e",
        "companyId": "f97da0ef-d374-4019-9369-5f8315aa6408",
        "companyName": "Company 2M",
        "productId": "9ac6ffaa-f58c-466a-a7d1-7d01f1787617",
        "productName": "Product B",
        "quantity": 1,
        "subscriptionId": "6230822b-fc68-4d0c-a60c-b12f311aded5",
        "type": "NetNew"
    },
    "provisionDetail": {
        "details": {
            "exampleCustomerData1": "collectedAtCheckout",
            "key2": "value"
        }
    }
}

A new subscription ID is created in Pax8, define S3 id = 6230822b-fc68-4d0c-a60c-b12f311aded5

We now have 3 subscriptions in the system. Ensure that your records have the correct quantities, products, partners, and companies.

Partner 1 buys a new trial subscription to Product B for Company 1M

If you don’t support trials, you can skip this kind of test, but this demonstrates how the type field on a provisionRequest has different semantics.

POST /provision-simulations/order-events

{
    "isSimulation": true,
    "provisionRequest": {
        "partnerId": "331684ad-5ad7-431e-9811-476813670a77",
        "partnerName": "Partner 1",
        "partnerDomain": "partner1.example.com",
        "partnerEnrollmentId": "0f872e4a-51cb-4ceb-b33c-914292958475",
        "companyId": "879812be-de5c-4c52-af49-dfb321f9bffc",
        "companyName": "Company 1M",
        "productId": "9ac6ffaa-f58c-466a-a7d1-7d01f1787617",
        "productName": "Product B",
        "quantity": 1,
        "subscriptionId": "004a4e33-d9c9-48c6-94d3-2f520a081f38",
        "type": "TrialCreate"
    },
    "provisionDetail": {
        "details": {
            "exampleCustomerData1": "collectedAtCheckout",
            "key2": "value"
        }
    }
}

A new subscription ID is created in Pax8, define S4 id = 004a4e33-d9c9-48c6-94d3-2f520a081f38

Validate that this new subscription is set to a “Trial” in your system.

Partner 1 Deprovisions S1

POST /provision-simulations/order-events

{
    "isSimulation": true,
    "provisionRequest": {
        "partnerId": "331684ad-5ad7-431e-9811-476813670a77",
        "partnerName": "Partner 1",
        "partnerDomain": "partner1.example.com",
        "partnerEnrollmentId": "0f872e4a-51cb-4ceb-b33c-914292958475",
        "companyId": "879812be-de5c-4c52-af49-dfb321f9bffc",
        "companyName": "Company 1M",
        "productId": "de533202-a97b-46ab-9476-32acb524393e",
        "productName": "Product A",
        "subscriptionId": "6129b9ef-1fc6-4379-8130-376463e88d71",
        "type": "Deprovision"
    },
    "provisionDetail": {
        "details": {
            "exampleCustomerData1": "collectedAtCheckout",
            "key2": "value"
        }
    }
}

As a result of this order event, validate that your records show that Subscription S1 is marked for deprovision and cancellation.

Querying Simulation Data

For a period of 7 days after simulated data is created, you can query it using your simulation credentials. For example, if a provision request is created as part of a simulated order, you can do a GET with the id of that provision request to get it from the Pax8 API. Or all of them will show up on the list provision requests endpoint.


What’s Next

This walkthrough illustrates just a few specific scenarios you might want to test. The simulation endpoint lets you craft your own scenarios, so don't limit your testing to just these ideas.