Sorry for the many consecutive posts, but I wanted to provide an
update:

I just updated all of our .NET Web service functions to call a central
function that uses an existing authentication token (or creates a new
one if the current one is over 24 hours old).

I then tried a batch creation of 1000 accounts, in which the .NET Web
service function is called 1000 separate times consecutively, each
time using the same authentication token to create a new google
account (in one of our test Google Apps domains).

Seems like some fewer errors in this test, but still the occasional
error.  Most of the account creations occurred within 6-10 seconds
(rarely quicker), but when a failure occurs, it takes 90+ seconds (or
sometimes even longer) for the Provisioning API to come back with the
"Request failed" error.

I've checked to make sure the host is not interfering in network
traffic in any way, and we've just completed a very large number of
mail migrations without any timeout issues, so I don't believe it's a
timeout issue or anything on our end blocking communications.  I've
also checked on the server running the .NET code, and it appears that
there is only one connection to the Google servers open at any time.

Any other ideas?


On Feb 10, 7:10 pm, Patrick <[email protected]> wrote:
> One additional question about tokens:  If I have the Web service
> function that calls the Provisioning API hosted on two separate web
> servers, would two separate authentication tokens be required since
> the requests are coming from two different IP addresses (even though
> it's the same username/password)?
>
> On Feb 10, 6:09 pm, Patrick <[email protected]> wrote:
>
>
>
> > Thanks for the ideas.
>
> > We are using the same random password for each account during each
> > batch.  (We use single sign on.)
>
> > We automate everything we can in our environment, so uploading a CSV
> > isn't really an option for us.
>
> > I'm interested in what you're saying about using a token, but I'm
> > afraid I don't quite understand how I'd use one.  I'm just using an
> > admin/password rather than an authentication token.  In addition, the
> > way we're calling our code, we're connecting to Google's API,
> > performing the function, then the code ends -- we have basically
> > created a .NET Web service function for creating Google users; that
> > function gets called once for each user.  I'm not sure if the same
> > token could be used across those separate function calls.
>
> > On Feb 10, 4:51 pm, NCCFred <[email protected]> wrote:
>
> > > Another thought, make sure the password you are sending meets the
> > > minimum criteria and doesn't contain invalid char's, etc.
>
> > > On Feb 10, 4:48 pm, NCCFred <[email protected]> wrote:
>
> > > > When you are creating a large number of accounts are you using a token
> > > > or just your admin username/password?  I had something similar but
> > > > that was with a CAPTURA issues.
>
> > > > I've personally had great luck with using a token with C#
> > > > applications.  I also do a lot of bulk account creations and it makes
> > > > life a lot easier to upload a CSV via the Domain Admin Dashboard.
> > > > Once its finished it will email you any errors that it came across via
> > > > the upload, IMO much easier to manage.
>
> > > > FYI, my student domain has 22,683 accounts.
>
> > > > On Feb 10, 4:44 pm, Patrick <[email protected]> wrote:
>
> > > > > By the way, even when it fails and throws that generic exception,
> > > > > often the account is created anyway.- Hide quoted text -
>
> > > > - Show quoted text -- Hide quoted text -
>
> > > - Show quoted text -- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Apps APIs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/google-apps-apis?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to