You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
Allan,
Your suggestion sounds great! I actually have several enhancements lined up for the API as well - mostly around making it a bit more failure resistant, since right now it will essentially just throw an Exception and terminate execution immediately if it hits a connectivity issue (which happens every once in a while randomly).
But, I hadn't even considered making the Omniture environments a configuration parameter, since i hadn't needed to. That said, I'd definitely welcome your suggested changes, and would definitely merge in a pull request from you, if you want to get that set up ..
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
The text was updated successfully, but these errors were encountered: