This year I’m using reverse psychology on myself. I will not blog. I will not blog. I will not blog.
Beta 3 of Alteryx Server.Next is just around the corner, so I thought I’d start adding materials that might be helpful for those who are brand new to the product. Some of this stuff will be high-level, some will be nitty-gritty technical.
Today we’ll talk about how Server.Next deals with data sources. We do things a little differently.
What’s a Data Source?
In Server.Next, a Data Source represents the “where” part of a functioning connection to any data source:
- The hostname of the server you want to connect to
- The driver you need to use
- The name of the database or share you want to connect to on the server
- The network port the database server is listening on (optional)
You can think of the Data Source as a hotel address and room number in that hotel: If you have this information, you know where to go, but you can’t get into your room yet.
Data Sources are found in the Data Sources list, accessible via the left-hand navigation bar in Server.Next.
What’s a Credential?
A Credential is a username and password used to access a database or data service. It’s useless without a Data Source, of course. Think of it as a key to an unknown hotel room.
We know that it’s no longer a “username and password only” world, so in the future, we’ll also handle tokens, keys, and even secret vaults.
Use the Credentials menu item on Server.Next’s left-hand navigation bar to see the list of Credentials on your system.
What’s a Connection?
A Connection is the combination of a Data Source and a Credential. If we use the hotel analogy, it’s your card key, encoded to let you into a specific room.
In the diagram below, two Connection assets are associated with a SQL Server Data Source. Each Connection is a combination of Data Source information (sqlserver.corp.com) and Credentials for that Data Source (user: Ted, password: 123 and also user: russ, password: yyy)
Note how the same credential (user: eric, password: foo) can be used in multiple connections. Credentials don’t have to be “technology-specific” since they are often simply key/value pairs. If I’m unwise enough to use the same username and password for both Snowflake and Oracle, then I don’t need distinct Credential assets in the Connections that access those sources.
Unlike Data Sources and Credentials, Connections are not directly accessible via the navigation bar. Instead, open up a Data Source you’re interested in, and you’ll see the associated Connections in the Connection List at the bottom of the page.
Since any given Data Source can have multiple Connections associated with it, you can tag a single Connection as your Personal Default. When the data source is utilized, Server.Next will execute with the Personal Default connection first. If NO Personal Default is selected for a Data Source, Server.Next executes using the oldest connection associated with the Data Source.
In the screenshot below, I’ve tagged my Personal Default against a Connection which utilizes high-privilege credentials. Note the second Connection associated with the Data Source – it is low-privilege.
- For a Data Source to be useful, it needs a Connection associated with it.
- A Connection is essentially the combination of a Data Source and set of Credentials
- A Data Source may have one or many Connections associated with it
- You may choose a single Personal Default Connection for each Data Source you utilize
How do I create a Data Source?
Navigate to the Data Sources list, and click the Add Data Source button. Data Sources are also automatically created when you publish a Workflow to Server.Next from Designer.
- You will first enter information about the server and database you want to connect to
- Next, the Add Data Source wizard will prompt you enter a Connection Name for the connection you’re about to create
- Part of the same screen allows you to Create a new credential or pick an existing one.
- If you create a new Credential you’ll be prompted to enter a Username and Password for the Data Source you’re accessing
The separation of secret storage from the data source plus the introduction of Connections allows you a LOT of granular control around sharing. We added a little bit of complexity here on purpose because the payoff down the road is worth it.
You can do all sorts of crazy stuff:
- Share a Data Source with an associated Connection
- Re-share the same Data Source with a different associated Connection to someone else
- Allow someone else to re-share the original Data Source with a different Connection
- Share a Data Source without an associated Connection
- Share Connections (which is pretty much the equivalent of #1, but more on that later)
- See and/or modify the username or password of a Credential in a Connection unless you’re the owner of the Connection
- See the password in a Credential, even if you are the owner or an administrator
- Directly share a Credential with a colleague
The way Server.Next’s Data Connection Manager (DCM) operates enables all of these scenarios (and many more):
- I share a “ready to eat” Data Source and low-privilege Connection with a colleague
- My co-worker uses it “as-is”
- My co-worker has their OWN set of higher-privilege Credentials and chooses to associate those with the shared Data Source in the form of a new Connection
In the screenshot to the right, I’ve shared my Data Source and a (lower privilege) Connection called Russell’s Secondary Connection to Ashley Kramer.
When Ashley logs into Server.Next and sees the Data Source, she decides she wants to use her personal set of database credentials with this data source. So, she clicks Add Connection.
She begins by specifying a Name for her Connection and also includes a passive-aggressive Description.
At this point, if Ashley had an existing Credential object which could connect to the database in question, she could select it. Since the drop-down says “No Results”, it’s clear that she’s going to need to add a new Credential, which will get folded into the Connection she’s in the process of creating.
- I share a Data Source without a Connection to the “All Users” group on my site
- Users who have a username/password for the database my Data Source uses can create a Connection & Credential, then utilize the Data Source
- Users who don’t have an account are out of luck – the Data Source is useless to them as it’s only a pointer to some data, versus an address and a “key to the door”.
- I share my Data Source to multiple users or groups, each with a different Connection.
You get the idea. Lots of options.
All Connections fall into one of two categories:
- Private (Default)
By default, Connections are private and cannot be shared. By extension, this means that the Credentials in the Connection cannot be “indirectly” shared by mistake.
To make a Connection Shareable, you must modify the Credential embedded in the Connection. You can edit the Credential directly in the Data Source’s Connections List by clicking on it. You can also go to the Global Credentials List via the Navigation Bar. It doesn’t matter. Edit and set the “Allow in Shared Connections” flag, and voila! Any Connections this Credential is a part of can now be shared.
So, you’ve modified a Credential by setting Allow in Shared Connections flag. Next, you share a Connection with utilizes this Credential with a colleague. You’re probably wondering:
- What Credential information can my colleague see in the shared Connection?
- Can my colleague re-share the Connection with OTHER people?
In short, your answers are “not much”, and “no”.
The ability to open and/or edit an embedded Credential in a Shared Connection is always disabled for non-owners. No one can see the username or password in the Credential.
Connections can never be re-shared. If you want to allow users to “re-re-share” (!) non-sensitive Data Sources, Alteryx Server.Next does allow that. Or not – it’s up to you.
Re-sharing and Unsharing Data Sources
By default, a Data Source that you share can be re-shared by the users who have access to it.
That said, the Connection (even if marked Shareable) cannot be re-shared. Earlier on in this post, I showed you an example of sharing a Data Source and Connection to Ashley Kramer. Here’s what she sees when she logs into Server.Next:
She has access to the single Connection which I sent along with the Data Source. Note that the Credential in the associated Connection has no blue hyperlink. It’s not clickable. Ashely can’t see usernames and passwords. That’s by design, as I mentioned earlier.
If Ashley wants to re-share this Data Source, she can reshare it without a Connection, or she can create her OWN Shareable Connection associated with the Data Source.
In this screenshot, Ashley went ahead and created a second Connection with her own credentials. She also made it Shareable by throwing the Allow in Shared Connections flag inside the Credential she created. Note the second Connection with a click-able Credential. Since Ashely created and owns this Credential, we’re going to let her open it. And no, we won’t show her the password 🙂
When Ashely re-shares this Data Source, she has the option of including her Connection, but NOT the Connection that was originally shared when I passed the Data Source along to her:
If you hate sharing
Maybe the thought of someone re-sharing your stuff makes you cringe. I get it.
If you’re that person, just make sure to use the Only Owner Can Share option in the Advanced Options of the Share dialog.
The same Advanced Options page gives you an easy way to revoke ALL shares of the asset in a single click.
It’s pretty slick!
To illustrate how this sucker works, I’m going to Remove Access From Others to undo all the sharing work to date.
Next, I’ll share the Data Source in question to Ashely again, but this time I’ll throw the Only Owner Can Share flag as I do so.
If Ashley attempts to re-share this asset, she’ll be warned off based on my use of the option above:
- Unless you own a Credential, you can’t see username information in the Credential. You can’t see the password, ever.
- Connections are Private by default but can become Shareable
- Data Sources and Connections can be shared, Credentials can’t be (directly, anyway)
- To make a Connection Shareable, throw the Allow in Shared Connections flag of the Credential in the Connection asset
- You can always unshare any asset and/or prevent users from re-sharing your stuff via the Advanced Settings dialog