Google I/O 2009 – Using the Google Secure Data Connector.. p
Articles Blog

Google I/O 2009 – Using the Google Secure Data Connector.. p

Good afternoon, everyone. My name is Jun Yang. Welcome to this session. I believe our session
has the longest title in this conference– “Using Secure Data Connector
to Access Enterprise Data from Google’s Cloud.” Don’t be intimidated
by the title. The most complicated part
of our talk is the title, which our marketing folks
struggled with for quite some time
before they settled on 11 words. So, okay. We have gone past now. So it should all be downhill
from here on. So in this session,
we’ll talk about how to use
Google’s Secure Data Connector to allow access
from cloud apps to your enterprise data. Now first I want to wear
the hat of an enterprise developer. I have a question. My question is… How can I access an on-premise,
relational database from Google Apps? Now, as you understand
as an enterprise developer, I have a lot of relational data in my intranet
behind the firewall. But I do want to use
Google Apps to get access to them so I can build interesting apps. Now how can I access an
on-premise, relational database from Google Apps? Now raise your hand
if you have the same question. Wow, a lot of them. You have certainly come
to the right place. For those of you
who have not raised your hand, you’re dismissed now. Just kidding. You can ride along. So, first,
let’s look at my data. Now here’s–I’ve got relational
database all over the place. And here’s a very typical
example of an employee table. It’s got a primary key. It’s got some columns–
varchar columns. Every one of the columns
is indexed for fast look-up. I have omitted some details
of the schema definition to fit this slide. Now let’s switch
to our database tool to show you my data. Now it just happens
that I’m using Postgres, but, you know, any database–
any relational database will apply here. So I’m using the database tool
to connect to my database
on my intranet. And let me just browse
to my database called feedserver. And it’s got a WiX schema. It’s got some tables
in there. Actually, one table,
for our example, the font is a little small, but here’s my schema definition in the season
and all that. So I routinely execute queries on my database, and here is one
of those queries. What it does,
it searches employees– the top 20 employees
in that database by using their first name
and last name and location. All the ampersands here
are wild cards. These are placeholders
for parameters we want to plug in later. So let’s see
how that query works. So I bring up my SQL tool. And I open up the two queries
that I have written beforehand. And this is a little small. But this is the same query
that we listed on the screen. It returns the top 20 rows
in this query using first name, last name,
and location against my employee table. So let’s execute that. And here we go. We’ve got our 20 items
returned. And, as you can see, I have a lot of data in my relational databases. I like that
because relational technology is a proven technology that works very well
for me. I like the fact that I can
execute ad hoc queries on my data and the fact
that I can just set up referential integrity rules and the database
will enforce them for me and other goodness
of relational technology. But the problem is my users
don’t use database tools like I do. You know, execute SQL queries for their daily work,
they don’t do that. What they want
is easy-to-use applications. And most of these apps today
are Web apps such as Google Sites, Gmail, and Spreadsheets. So we will see
how we can enable my users to be able
to access the same data from Google Apps. We’ll make a proposal
for a solution. And this proposal
has two steps. First is we will turn
my relational data into a standard format– the format is called AtomPub
or GData– that Google Apps can consume using an open-source product
called Google FeedServer. And the second step
is we will enable secure access to that data
in the standard format using another
open-source product called Google
Secure Data Connector. The agent part is open-source. And a little bit of word
about AtomPub and GData. AtomPub is an open standard
for data format and also RESTful APIs
for the other access. And GData is Google’s
implementation of that standard. And that is supported
by many Google apps. And there are client libraries
in various languages such as Java, JavaScript,
PHP, .NET, Objective-C, to name a few. And we will use
those client libraries in our demos today. So we have not invented
any new format here. We’re just using
an existing standard. Now here is the architecture
of our solution. At the bottom,
I have my relational database inside my firewall. And on the top,
I have cloud apps in different forms
as gadgets, as App Engine apps, as Spreadsheets, that I want my users
to be able to use against my own data. In the middle,
we can see the bridge between the two. The bridge consists
of two parts. One is FeedServer. That translates a relational
data into a standard format like we said before. And the second
is Secure Data Connector Agent that makes that data available to Google Apps securely, to lift up my data
into the clouds, so to speak. Now first let’s install
FeedServer. And this step I have done for our demo. But on the other hand, it’s actually pretty simple. You just go to this site, and the documentation tells you
how to download the code, compile it, configure it,
and run it. And we’ll show you
how we have configured it in the next slide. Here’s how
we have configured it. First of all,
to connect to my database, I need a database role account. So in my
file, I specify that. I specify which JDBC driver
to use. By the way, FeedServer uses
a JDBC adaptor to do the translation
between relational data or to do the translation
between JDBC, which is the standard
Java Database Access API, and AtomPub. So we use that JDBC adaptor
in FeedServer, and here’s how we configure it. We specify which JDBC driver
to use– in this case, certainly,
Postgres, a JDBC driver– and which database
to connect to. The database is on mydb:–
you know, that port, the database’s feed server
called FeedServer. And the database role account
is called FeedServer and the password. Um, and also connection pool
parameters I have omitted for the whole thing
to fit in the slide. And you have full control
of connection pool parameters. So as you can see, that as a DBA– My DBAs can create role accounts
for FeedServer access, they can limit the privileges
of these role accounts and also create different role
accounts for different feeds. So DBAs still have full control
of what access to give to which part
of FeedServer. Next, um, need to transform
my request, the URL request, into a SQL query. Right?
This is what we want to do. So on the top is the URL: /resource/employeeSearch. And with two URL parameters:
One is name. One is location. So at the bottom
is the definition of that transformation
from the request to a SQL query. As you can see here,
the select query is what we executed before. And instead
of those % wild cards in there, I have put #name# in there, so that I can pass these
parameters from the URL into it. So for–the red ones
are basically defining the mapping
between the URL resource– resource pointed to
by the URL– and a SQL query,
so employeeSearch maps to employeeSearch.xml
configuration file. And the blue ones
are parameter mappings, so the name John
will be passed into #name#
at runtime by FeedServer to be executed
on the database. And next, now that the query
has been executed on the database, we needed
to transform the results set back
to an Atom response. And here’s how we do it. All those orange ones
are result set column names. So lastname, firstname,
you know, all lowercase, these are database column names
returned by my SQL query. And the blue ones
are AtomPub property names. So here I do the mapping. Although I’m only changing
the capitalization, in reality you can do whatever
kind of mapping you want. You can change “firstname”
to “givenname” or whatever. And the green… is a HashMap. It’s a generic data type that we use to store
the result set so that we don’t need
to do any programming on the server
for this demo to support this kind of– any kind of queries. Now that we have configured
our FeedServer, we are ready
to test it. Now we run this query against–that curl is basically
a command line HTTP client that allows us
to exercise our FeedServer. I have already started
FeedServer on my machine in my intranet. Now let’s do that query. So let’s just copy that. And execute it here. It gives us a bunch
of XML. Wow. We cannot really
easily discern that, so I have loaded that
into a file for us to browse
in a browser. So let’s enlarge this
a little bit. So that says it’s a query
against this URL. And it returns 20 entries there. Top entry is this. As you can see,
Atom property names with capitalization
in the middle, CamelCase… or what we define for
transforming the results set back to Atom properties. And in here,
the top entry returned is somebody
called Phyllis Aaron. And if we switch back
to the database tool, we can see
that Phyllis Aaron is, indeed, the number one row
in there. Okay. So here we have configured– installed and configured
and run FeedServer, and we are halfway there. Now that we have the data
in the standard format, we still need
to make the data available to Google Apps. Now how do we do that? Enters Secure Data Connector. Now how we install that
is we go to this site, and we follow
the simple instruction there and install it, which I have done, obviously,
for this demo. And what we do next is I need to enable
that feature in my Google Apps domain. So my test domain
is called As an administrator
of that domain, I go to this site,
Google Apps Control Panel, and I click on this link, “Activate and configure
Secure Data Connector” to allow this feature
to be usable. So this is one
of the examples of multiple control points that we allow you
to have your control. Basically, you need
to allow that. You need to configure
FeedServer, configure SDCs
and different access rules to allow your users
in the cloud to access your data. And the next
is an access control rule. So this is one simple rule for the Secure Data Connector
Agent. What it says is
for the user [email protected] from the cloud, only this URL,
which is a host,, is allowed for AppEngine app called java-sdc-io. So that limits by user, by app, and by URL patterns. And similarly we can do this
to allow access from gadgets
and Spreadsheets, which I have done
for this demo. Now Secure Data Connector
is configured. Now we can run that
with that first command. And, as you can imagine, I have already run that. And, let me see. In the second command… second command shows–
allows us to watch the log of SDCs. You can watch the traffic
between Google and SDC and see who’s accessing
which resource. So we’ll run that. And later on
during the demo, we’ll point back
to here to point out interesting things in the log. Okay. So we’re just watching
the log, and we’ll switch back
to here later. Now we have configured
both FeedServer and Secure Data Connector. As you can see, we haven’t written
one line of code so far. All right. Um, actually, in this demo,
we will not be writing any server-side code. The next is we’ll write
some client-side code to use the data, turn it
into the standard format, and made available
to Google Apps. So, first,
let’s write a gadget. Now here’s the main code
in that gadget. It’s a search function that takes a name, a location,
and a continuation function, or a handler of data, and executes the request
to my data. As you notice that– the host name and port pattern is what I enabled
in my SDC access control rule. Right? And the red is still the same
as before. It defines the mapping
between a URL resource called Employee Search
which SQL query to execute on FeedServer. And the blues
are the same. Those are parameters
on my URL that will eventually be plugged
into my SQL query to execute. And the green ones… the green parameters instruct
Google to route this request through SDC
to the FeedServer that runs in my intranet. And also SIGNED–
well, that specified by ENABLE_PRIVATE_NETWORK. And also SIGNED says encrypt
the authentication information and send that through SDC
to FeedServer so that FeedServer
can decrypt that and know which user has come
to request the resource. So the flow goes roughly–
the user would log in to, for example, Google Sites, and the log-in can be integrated
with your LDAP through sample integration for single sign-on. So the user will use
exactly the same identity as if
inside your corporate network to log-in to sites and then go to this gadget
we’ll demo in a bit. And the authentication
information will be encrypted and sent through SDC eventually to FeedServer,
and FeedServer will decode that and know which user has come
to access the resource. And then you can enforce
more ACL rules at that point. So that’s roughly–
roughly the flow. And then the rest
of the function, it’s very simple. It basically creates
a service object, it sets some parameters on the service object, and then it does a getFeed
on the service object. And then it uses
that continuation function to handle the list
of employees returned as response.feed.entry. It’s an array
of employee objects. Now we’ll see how well it works. Okay, let’s switch to the demo. Okay, here’s my gadget. I have already logged in as [email protected] Now let’s do a search. That’s pretty good. That’s pretty fast. As you can see
that the top row there is Phyllis Aaron from sales. And she’s in Building 2 in the San Francisco office. Just for the fun of it, let’s switch
to the database tool, and then let’s say
Phyllis has just moved to the Chicago office. Let’s do an update here. And if we do the search again… you can see Phyllis Aaron
on the top has moved to the Chicago office. And notice how fast it is. This request goes
from the browser to Google
to SDC server to SDC agent that we installed
and run in the intranet and then to FeedServer
running on intranet and to my database
running on intranet and all the way back
in under a second. Okay, so next
let’s try some other queries like, let’s say, let’s find
all the Johns in the company. Now here are the top 20 Johns
in the company. Now let’s say it’s the
top 20 Johnsons in the company. How about those Johnsons in Mountain View office? Well, still pretty fast. So that works pretty well. Next, let’s see the App Engine version. Now for the App Engine version,
first, what we’ll do is we define a JavaBean
called Employee to hold those properties. The first property–
I have only included first property lastName in here. But the other properties
you can imagine are defined very similarly– firstName, location,
officePhone, and things like that mapping to columns–
Atom properties– mapping to Atom properties
that I have defined. And at runtime,
our client library turns those Atom properties
into properties on your Bean automatically. The next code snippet
is what I do in Java AppEngine
to issue that request to get the list of employees. As you can see this is somewhat
similar to the JavaScript code. What I do here
is I create a service object first, then I set some parameters
on the service object. In this case,
the green parameters instructs Google
to use_intranet to route the request
to SDC and then eventually
to FeedServer and to our database. As you’ll notice,
here the URL is the same as before. And the resource that we access
the same would pass the parameters’ name
and location similarly. And even better
than the JavaScript version, we get a list
of Employee back. Employee is my data type. And I get my data type back
correctly. So that’s pretty easy, right? Let’s see how it works
in the demo. Now here’s my… App Engine app
running at, as you’ll notice– it’s a little small,
but java-sdc-io. That’s the App Engine app
that we allowed in our access control rule,
right? So let’s execute our query here. Say search for top 20 employees
here. Well, this time the performance
is not very consistent. Let’s see. Let’s try again. This time it’s faster. Okay, so all the queries
are not cached. So again the top one
is Phyllis Aaron. Okay, so I can search
for other people like before. All the Johns. And it’s pretty fast. We’ll do Johnsons. Yeah, okay. So that works pretty well too. Now we have written
some client-side code, right? Java and JavaScript
to enable access to my employee table. Can we make that
even simpler? I guess the answer
is yes, we can. So next let me see
how I can make that even simpler
by going to, say, spreadsheet. This is a blank sheet. What we plan to do
is we plan to put our name here, the name to search for
in B1, and our location to search for– I can spell that– in B2. And then construct that URL,
and then access the URL, and display the data
right in my sheet. That’s our plan. Okay. So here are two formula
that I’m going to use. One is CONCATENATE the string. Plus B1 is where we will store
the value of the name and B2 where we will store
the value of the location into this access URL
that we want to use to execute
against our data source, FeedServer, basically. As you can see, blue,
you know, other parameters. And the number here
is a cache buster. Basically, we cache data
for a certain amount of time, but for this demo
to work live, right, when I change data,
I want the change to be reflected on the UI
immediately. We can put in a random number
to indicate this is a new request
every time. And the second formula
I’m going to use is importXML. It uses the URL constructed
in C1 and does that request and then says, okay, display all
the data elements called entity. And entity is a generic term
for all the rows returned in my database. So every entity is an employee,
basically, in our case. So just gonna do that. So let me just copy
the first formula… and then plug that
into my spreadsheet. Okay. Now I’ll plug in
the second formula… into this. Let’s see if there’s an error. A1, A2. No, no, no.
B1, B2. They’re the value. I’m going to–yeah, sorry. Okay. All right. Okay. Let’s see if we can spot
the error here. Oh, yeah, of course. Single quote. Convert to double quote. All right.
Here’s my data. As you can see that
Phyllis Aaron again is on top. And we can search
for other people. And those Johns in, say,
Chicago office. As you can see,
the performance is pretty good. And, um… we can modify the data again. Let’s, say, move Phyllis
to New York office. Let’s execute that query. Change that in my database. Then switch to my spreadsheet. Oh, I need to change
the magic number so that I don’t hit the cache. As you can see,
Phyllis Aaron has moved to New York–
New York office. Okay. So in a very short time,
I think in… about a half hour,
we have built three fine apps to access the same data
that is behind the firewall in my relational database. And we can do a lot more
than that. Let’s–let’s review
what we have done. Okay, so what we have done is we have mapped
relational data to Atom feeds. That’s the standard format
Google Apps use. And we have connected
behind-the-firewall data to Google Apps securely. And we have specified access
rules to control who can access what
from where. And we have written
three clients for the data. And I think it’s important
to point out what we didn’t have to do.
Okay. So we didn’t have to write
a single line of code on the server. And we only did
the configuration in one file to map request
to SQL query and then from SQL’s result set
back to a response. And we didn’t have to set up a firewall hole
in our firewall. And we didn’t have to use
complex firewall configuration to allow Google to access
my data. In fact, from Secure Data
Connector agent to Google is an outbound call. There’s no firewall hole
required. And from the Secure Data
Connector agent, you can control what Google can access
what–when. And there’s
no special configuration for the three client developers,
right? One JavaScript, one Java,
and one spreadsheet developer. There’s no special configuration
for them. What they understand,
for example, in Java, I’m just dealing
with my JavaBean, a list of employee objects. No.
How simpler can you get, right? So they don’t know the existence
of FeedServer in the middle, you know, Secure Data Connector
enabling the data for Google Apps to use. It’s very simple for them
to develop their apps. Then what’s next? What we have now demonstrated in our demo
is you can write data back to the database. It’s fully supportive.
You can change, you can delete. You know, those requests
will be mapped to update, delete,
and other SQL queries. And you can also manipulate
and process the data in the cloud. You can execute
your business logic in the cloud. For example, when something
happens, send an email. When something happens,
create a calendar event in somebody’s calendar. And we can integrate
your PRAM behind-the-firewall enterprise data
with the rest of Google Apps. And, in fact… our next demo will have
a Google Apps script demo, which we just introduced
recently. And here’s Jonathan Rochelle
to do that demo. [applause] Rochelle: Hello. I’m going to try
to do something amazing here, which is set up
for my demo while I’m talking. Which might not be possible. So I’m going to talk
about Google Apps script. It feels kind of natural that you want to get
your own data and then you want to do things
with it. And so Google Apps script
lets you do things with that data, lets you do things
across Apps. So I’m going to actually log-on
to a domain– a test domain… which has some examples on it. Normally, I would do this
before I came up here, but we didn’t have the luxury
of two machines here. So… So I’ll just quickly describe. What Google Apps script
does for you is it lets you automate actions
across Apps. That’s a fairly generic way to
say that it lets you do things that you would normally do
manually. It starts in Spreadsheets. It’s intended to do
more than that, but in Spreadsheets, there are very specific things
you can do. You can create custom functions, you can access and edit data or formulas or formats, you can do the things
you would almost expect to be able to do
in Spreadsheets. And then it goes outside
of Spreadsheets to reach into Calendar, to be able to create
and look at events, to be able to look at mail
in a very limited way, to be able to send mail. Okay, so there will be
other things you can do with mail eventually, but right
now, it’s just sending mail. And you can do other things
as well. Grab data from a Web page
and investigate it, look at it, do things,
act on it, do URL fetch, get in post, and translate
to other languages. So I’m gonna show you
some of those examples. I’m gonna focus
on three examples. The first is fairly simple. It’s a custom function. And these custom functions
are extremely straightforward. They’re written in JavaScript. All of Google Apps script
is JavaScript with the extensions
of the objects that we give you access to. So the way you access
Google Apps script is through the Tools menu. And right now,
just to clarify, we’re actually
in a limited test mode. So you have to apply
to get your domain activated, and once it is activated, you can access the way
I’m showing you now. And I’ll tell you now, just
in case you want to visit– we actually have the link linked
from the Google enterprise blog, which is It’s still–I’m not gonna go
into the detailed URL. It’s still the top post, so you should be able
to find it no problem. But from the Tools menu,
there’s a Scripts sub-menu, and you go to Edit Scripts. And I’ll just very quickly
show you the code of these custom functions. And a script can contain
more than one function. So this script
is called Convert. It’s got two functions
in it. The first is the inches
to millimeters function. It is definitely not the best
way actually to write a function that’s gonna do conversion, you know, to have each function
for every single conversion you’d want to do, but I just
wanted to illustrate the point. You can see
it’s just plain JavaScript. There’s a declaration
of variables, there’s a quick test
to look at the input and to return something
in the cell that says it’s an error if it is, to do the simple calculation, and then to return that value
to the cell. So when you have
a custom function, it’s expecting an input, and it’s gonna basically
give you an output. So what you can see here
is I’m calling that function as a normal formula is called
in a spreadsheet. And it’s calculating the results
for me. So if I change the input, it’s gonna calculate the output. So it’s very, very standard. And you can basically, you know,
do everything you can do with a… spreadsheet
once you have that function. Again my formats
are a little wacky there, but I’ll just show you quickly
how it would work if I’m doing
parallel calculation. It’s gonna–no, it didn’t do
my extension for me. I messed that up.
Sorry. But you can see what the gist
of it is. So in case any of you are
looking to convert many inches to millimeters, I’ll sell you
this custom function. It really, really took me
a long time to develop. Actually, it literally took
about five minutes to develop that one. The longest time was just going
to Google Search and figuring out what the factor
was to multiply by. I didn’t have
that one memorized. So the second example
I want to show you goes beyond, so you saw
how to actually access script– it’s in the Tools menu– and how to do
a custom function very simply. And again, once you have data
pulled in through SDC, there are things
you want to do with that data. That’s kind of the whole point. This example might be
a little bit more relevant. We use this one
in Google a lot now. This is generally–
if you look at the abstract of this example,
it’s very popular, which is– forms are used prolifically
at Google and other customers. And one of the things
you want to do is look at the data that came in
on a form the same way you’d look at data
that came in through SDC and do stuff with it. This one is going to send
confirmation emails, so you can manipulate the data
potentially that came in or look at it
and approve it and send emails. What I want to show you
in this example is the two ways
that you can execute a script. And this script
is not a custom function. This one is just processing. The two ways
are through a drawing object– the drawing object
can be assigned to macro, so you’ll see, like,
I have a small menu. It’s a little bit hidden
under my scroll bar there. But I can assign a script, and I assigned a name
to that script: emailConfirm. And the other way
is through a custom menu. So you can see
that Confirm custom menu with just one option here,
which is Send Confirm Emails. What this script does
is it looks at this field to see
was this confirm ever sent. And if it was,
it won’t send it, but if it’s not,
it will. So I’ll click on that button. And it’s running the script. You can see it’s started, and now it’s marking them
as sent. And it’s giving me a timestamp
as well. So if I wanted
to resend it, you know, I could basically
blank this out and resend,
and it’ll send it again. So I’ll quickly jump to– well, I shouldn’t say quickly ’cause I’m just not fast enough
typing when I’m presenting. But I’ll jump
to my mail account so you can see the email. The email that came in
was defined by my script. My script said, what do I want
that email to contain? So you can see all
those responses just came in. And within the last minute. And the contents
of that email is defined by my script. I put in there
what I wanted to in the format
that I wanted. So it’s an HTML string
basically that I sent out to that email. I could also create attachments and formulate those attachments and put them
in that email payload as well. And they would come through
as attachments, which is kind of neat. We actually do that. For the documentation
of this product, we’re creating
that documentation in an automated way
using script. We have a spreadsheet
that contains all of our documentation. Anybody on the team
can go in and change things,
fix things, whether they’re engineers
or not. And then somebody pushes
a button, and it sends all that stuff
over to the webmaster to put in the help center. So it’s really
an interesting way to– I have to say, the attachment
process was created– that feature was created
specifically for the team. I guess when it’s something
that they’re asking for, they get to put it
at the top of the list. So the third example
is translation. This is using another one
of these objects, these Beans, which also illustrates
one more point, which is just analyzing or using
my currently selected range. So this is a rather,
in some ways dumb function, which is, it’s just gonna take
what I selected, it’s gonna translate it
and throw it to the right. It’s just gonna put it
in that highlighted area that I have to the right. And again I created
a menu option for that. And I, in this case, created
four different caller functions so that the menu can be
a little bit more user-friendly, and I’ll say, “Let’s translate
that to Spanish.” It started running the script. You can see down below
it’s doing the translation And when it finishes, it’ll say
that the script is finished. And the results
are there. And that again,
like I said, there’s so much you can do
from that point. This is really
just to illustrate. One of the, you know,
really obvious examples is to be able
to translate content and email it to someone
who’s not even on the product. So you could actually do
translation and send information to customers or partners. I’ll show you one more thing
that’s just– at the risk of it not working just because I wrote it late last night– which is a conversion function. Since I showed you
the wrong way to do inches
to millimeters, I’ll try to show you
a better way. This is actually translating
different things. What I did is I’m translating
from U.S. dollar to euro. And, you know, that should work. Let’s see if it changes that. But I can also say
that I want to translate from feet to, I don’t know,
somebody give me– what do you want
to translate feet to? Yards. Hey, 30 feet is 10 yards. Um, yeah, I can even– you know, I can do liters
to gallons. Pretty much anything. And the way I do that
is through URL fetch. I’m using Google Search. I’m using the IN operator. I don’t know
if anybody’s ever used that. But I just basically formulate
the search string, and then
when the payload comes back, I look at the string, and I came up with a very–
this is the only thing that took any time– was I look at that data
that came back, and I find the answer. So if you look
at this script, it’s fairly simple,
but convoluted. This is a great sign
of my horrible coding. But it’s mostly comments
actually. But I have to find
the third table and find the equal sign
and look for the units and I’m there. But it’s just an example
of how to actually call out to external services, whether they’re your own
or something else, through the URL fetch option. And that’s pretty much it. The most important thing here, I think,
is the extensibility. We’re gonna be adding reach-out
to other Google apps, as well as non-Google apps
at some point. But very, very shortly, you’ll be seeing enhancements
to this, and, like I said, go to if you want to apply
to have your domain in this limited test
that we’re doing right now. You know, it’s likely that
you can be accepted into that. And fairly soon, you’ll see it launched
across all of Google Apps. And that’s it. Thanks.
[applause] Are there–do you want
to take questions now? Do we have time
for questions? Great. Do they have the mic on? man: There we go. Um, question about–
two quick ones. One about the email. You mentioned
that you can put attachments on that
for sending out the email. Can you format the attachments
to be in line or just payload attachments
on an email? Are there ways
of configuring that so that, say, can you format
as HTML? Rochelle: Um, you can
pretty much do anything. In other words, that attachment
is really, literally, just a bit stream. It’s a blob.
man: Okay. Um, the other one is,
you mentioned, in the little script
you wrote to convert, you looked
for the unit character. How do you find the units? Rochelle: It’s really
just pattern matching. It just took some testing,
to be honest. I mean, if you could see me
writing this thing, it was almost funny,
’cause I just kept returning whatever I could find
until I narrowed down, and then I had to find
some crazy ASCII character that represents a comma. It was insane. But it was simple to write
and then hard to perfect. And I would say
it’s still not perfect. But it is useful actually. man: So one thing
I haven’t seen yet or heard anyone talk about is, what are the scalability
and deployment guidelines for the Secure Data Connector
on my server? I mean, it’s deployed to one box is what it looks like here. If I have 50,000 employees,
how’s that gonna work? How many boxes
does it deploy to? What’s failover? Can you guys talk about that
at all? Yang: Yeah, there’s more
documentation on the site, but, in short, basically,
you can run multiple instances of the SDC agent,
and they failover to each other. man: Okay. Rochelle: Any other questions? Yang: Any other questions? man: When is this gonna be
broadly available? Rochelle: I’m sorry.
Say that again. man: Accessing data, say,
behind corporate firewalls– Rochelle: Secure Data Connector?
man: Yeah. Yang: What I have demo’d today
are all in production. So you can do it today. And the two products
are open-source products, so you can download
and configure and run yourself. Rochelle: Yeah, so the limited
test that I was talking about was literally
for Google Apps script, not for Secure Data Connector. man: What about dynamic data
in forms? Yang: What?
man: Spreadsheet forms. Rochelle: I’m sorry, say that–
man: Forms. Rochelle: Yeah.
man: Spreadsheet forms. I don’t know if there is a talk
specifically on forms, but a big need we have
is making dynamic forms or more, you know, responsive,
to actual data. Rochelle: Yeah, so one
of the things that we expect to add to Google Apps script
is event processing. So I’m thinking–
you tell me if I’m wrong, but what a lot of people
are asking for is to do things like,
when a form submission comes in, do something. Is that what you mean? man: Well, no, actually,
pulling data, creating dynamic questions. Rochelle: Ah, okay.
man: From a data source. Rochelle: So, yeah,
that’s interesting. Since we don’t yet have
a good API into the forms capability
of Spreadsheets, we don’t have anything
on script that reaches into that. But we do expect to do that. It’s just not there yet yet. Forms is an incredibly popular
feature right now, so we expect to do
a lot more with that. Okay.
It looks like we’re done. Thanks. Yang: Thank you.

2 thoughts on “Google I/O 2009 – Using the Google Secure Data Connector.. p

  1. Can the google visualizations use the feedserver as data source?. I do not see any examples showing use of google data feed server for visualizations.

Leave a Reply

Your email address will not be published. Required fields are marked *

Back To Top