Q&A: Social Media and Cloud Application Integration in Centerprise

Q: Can you talk about security and different authentication mechanisms available for REST calls.

A: Centerprise is the tool, but not the application. You’ll need to register an application for the web service provider.   Say there is a registration for box.com using OauthV2. They will give you an application key as well as an application secret and you’ll get back an access token, which you can use along with a refresh token to authenticate yourself. You can think of this as a valet key.

OauthV1 works similarly. When you click on “Generate” you can see that there are end point variables, shown in the left column, that help us fill in the other points.

When you select the service and sign in, a website will be presented (shown in blue) that is a three-part handshake. You fill in the key and confirm to the service who you are and you will be given an access token. From then on you’ll use that access token to get data back form the service.

Oauth V1 is more complicated and most sites are now moving to Oauth V2 because it is simpler. It doesn’t require as much handshaking and relies completely on SSL for security, as opposed to Oauth1, which uses an additional encryption method.

Q: Can you describe how to build the layout for REST click call for mapping?

A: First you need some sort of layout because you are sending a payload. The payload you’re going to send depends on what the actual web service call body structure looks like.   As an example, let’s look at Updating Tickets. For Updating Tickets, if you scroll down you can see that it provides the documentation you’ll need under Request Parameters.

It is a very common mechanism for web service providers to detail how to work with their service. Because there is no WSDL editing tool for REST services, they have everything in documentation. Many provide some sort of sample request that you can use for your structure.

If you click on the option “use sample text” and then “build layout,” the request will then run and will give you that structure.

Now that you have the structure you can see that it shows up in your tree (Figure 7).

Q: What are the deployment options for dataflows containing web service calls?

A: All the authentication passwords, etc. can be parameterized and stored in a file. For services, you select Schedules.

You’ll see that you have Job Parameters.

Any time you use a service you’ll find it in Job Parameters along with the credential information. You can replace the access token and the refresh token so that you don’t have to keep sending it. Also, you can drive the service through an external configuration file and then when you deploy it all your credentials for that service will be there. You can specify in the file whether it is a sandbox service versus a real service.

Q: Are the calls to your service synchronous or asynchronous?

A: Currently they are synchronous, but the next version of the software will include an option for asynchronous as well.