Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting for specific URL environments/subdomains #1

Open
allanjamesvestal opened this issue May 31, 2012 · 1 comment
Open

Setting for specific URL environments/subdomains #1

allanjamesvestal opened this issue May 31, 2012 · 1 comment

Comments

@allanjamesvestal
Copy link

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

@RobGoretsky
Copy link
Owner

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 ..

Thanks!

-Rob

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants