1. How often should the queue of
orders that the Pending Order API exposes get cleared? Should an order be
removed from the queue a) after it's been polled, or b) only after the
corresponding subscription has actually been provisioned?
a) seems to make more sense. That means that the API will only respond with a
pending order once - after an order has been retrieved it will never be
included in a response again. The pre-processor will need to either provision
the corresponding subscription right away, or store its own queue of pending
orders on the Odin side. We agreed that it probably makes sense for the
pre-processor to just execute the provisioning commands as quickly as possible
Option b) could result in a growing
backlog of pending orders and consequently a ballooning API response size.
NOTE FROM AH: We reversed course on this one and decided that pending orders
should remain in the API response until we call back and confirm that they are
provisioned on Odin.
2. Once the pre-processor receives an
order, what happens next?
will probably execute provisioning commands as quickly as possible after
retrieving pending orders from the API.
3. Resellers will already need to be
on-boarded on to the Ingram Micro marketplace for the steps above to work. How
do we make sure that happens?
partners that already transact through Ingram's traditional channel, Ingram
will run a campaign urging them to onboard, and educating them about the
process. For partners that are new to Ingram, Symantec will run a campaign of
4. What data does the pre-processor need
from the API in order to execute the provisioning commands?
same data that the Odin platform needs right now to provision subscriptions.
We'll come up with a detailed list, but generally: product, billing, and
customer information. Most critically, the pre-processor will need a way to
identify which partner to provision the subscription for.
5. Couldn't there be an instance of the
pre-processor for each partner on the Odin platform, pinging the API on that
but that's a lot of unnecessary overhead and load on the Ingram side, not to
mention unnecessary traffic - the vast majority of requests will come back
empty. It makes more sense to implement a single pre-processor for each L1
endpoint (i.e. country marketplace) in the Ingram channel. These have a 1x1
relationship to TPCodes on the Symantec platform. So the request from each
pre-processor will be: For this TPMCode, provide me a list of pending orders,
along with corresponding Partner IDs.
6. Which Partner ID should the API respond
with to identify the owner of a given pending order - the Odin Reseller ID, or
the Symantec Partner ID?
could be either. We currently think that the best approach is to use the
Symantec Partner ID. To make this work, we need to ensure that when we onboard
a Symantec reseller on to the Ingram Micro platform, we capture and store the
Symantec Partner ID in the Odin account record. If the preprocessor can't find
a given Partner ID for a pending order, it won't execute the provisioning
command, and it will respond to the Symantec platform with some kind of
"Partner Not Found" error.
7. Could a given Ingram L1 endpoint (i.e.
country marketplace) ever correspond to more than one Symantec TPCode?
don't think so.
a given Symantec Partner ID ever correspond to more than one Symantec TPCode?
don't think so.
9. Does the polling approach work for
Ingram Micro? Should we consider some kind of push mechanism?
is probably fine.
JSON payloads for requests and responses work for Ingram?
is probably fine.
11. Is there any API reference
yet. Symantec will create some.
12. Will this approach require any APS
this point, we're thinking no.
13. Not to get too pushy or anything, but
how long do you think all of this will take?
going to take the next two weeks to find out, then re-group.
14. Where will we roll this out?
Ø In the
USA first, and then globally.