IM Cloud Knowledge Base
Quick Jump Menu
SEP Cloud Migration - FAQs
Article Reference NumberAA-11461 Views20

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?

Ø   Option 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 after polling.

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?

Ø  The-processor 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?

Ø  For 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 their own.

 

4.    What data does the pre-processor need from the API in order to execute the provisioning commands?

Ø  The 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 partner's behalf?

Ø  Sure, 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?

Ø  It 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?

Ø  We don't think so.

 

8.     Could a given Symantec Partner ID ever correspond to more than one Symantec TPCode?

Ø  We don't think so.

 

9.    Does the polling approach work for Ingram Micro? Should we consider some kind of push mechanism?

Ø  Polling is probably fine.

 

10.  Do JSON payloads for requests and responses work for Ingram?

Ø  JSON is probably fine.

 

11. Is there any API reference documentation yet?

Ø  Not yet. Symantec will create some.

 

12. Will this approach require any APS package changes?

Ø  At 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?

Ø  We're 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.