Hello,
First, thanks for this great tool! It's proved quite useful in some of my work already, and I'm just getting started with it.
In my initial work I've found some Omniture/SiteCatalyst clients can only get data from certain "environments" — that is, subdomains configured to serve the Omniture API. For example, 'api.omniture.com' represents the API environment based in San Jose, 'api2...' the one in Dallas, 'api3...' the one in London and so forth. There are also a few environments that follow the pattern 'beta-api.omniture.com', and one or two others as you can see in the API explorer (https://developer.omniture.com/en_US/get-started/api-explorer).
My company can only retrieve stats from the Dallas environment. For now I've just hard-coded the 'api2' subdomain into my copy of this script, but would it make sense to allow omniture_py users to customize this without having to edit their code?
I'd imagine the following solution: a user could optionally pass a subdomain argument when they instantiate the OmniturePy() object with username and shared secret. Such a convention could also be useful in setting the API version (another param in the URL), especially as I see they're now on v1.3 where your code still calls v1.2.
I could help implement these changes in the next month or so if you think they'd be helpful (and in line with your existing code). Wanted to ask if you had any plans to do so first, though. And to see if this would be the best way to solve this problem.
Thanks for the feedback, and for this API wrapper.
~Allan James Vestal
Contributing Developer
Los Angeles Times | latimes.com
Hello,
First, thanks for this great tool! It's proved quite useful in some of my work already, and I'm just getting started with it.
In my initial work I've found some Omniture/SiteCatalyst clients can only get data from certain "environments" — that is, subdomains configured to serve the Omniture API. For example, 'api.omniture.com' represents the API environment based in San Jose, 'api2...' the one in Dallas, 'api3...' the one in London and so forth. There are also a few environments that follow the pattern 'beta-api.omniture.com', and one or two others as you can see in the API explorer (https://developer.omniture.com/en_US/get-started/api-explorer).
My company can only retrieve stats from the Dallas environment. For now I've just hard-coded the 'api2' subdomain into my copy of this script, but would it make sense to allow omniture_py users to customize this without having to edit their code?
I'd imagine the following solution: a user could optionally pass a subdomain argument when they instantiate the OmniturePy() object with username and shared secret. Such a convention could also be useful in setting the API version (another param in the URL), especially as I see they're now on v1.3 where your code still calls v1.2.
I could help implement these changes in the next month or so if you think they'd be helpful (and in line with your existing code). Wanted to ask if you had any plans to do so first, though. And to see if this would be the best way to solve this problem.
Thanks for the feedback, and for this API wrapper.
~Allan James Vestal
Contributing Developer
Los Angeles Times | latimes.com