Managed Connections

Lesson 3 - Managed connections and the cConnection class

In the previous lesson we talked about the connection string and ID. In this lesson we are going to dive into the cConnection class.

Even though DataFlex has always used connection strings and IDs, the advent of Managed Connections in DataFlex 19.0 fully integrated the basic concepts into the application framework and tools. As we discussed earlier, the fundamental building blocks are having the full connection string mapped to the connection ID in the workspace configuration file and are specifying which connection ID to use in the table intermediate files. 

This is all done through the cConnection class…

DataFlex uses the cConnection class for SQL drivers that support connection IDs. It is represented as a single, global object that supports:

• adding and managing connection ID / connection string pairs,
• using those IDs in the table intermediate files,
• storing the IDs in a central, workspace-centric location, and
• using them to login to one or more database servers.

The cConnection class provides a complete, extensible interface, which includes…

• The ability to add, edit and remove the connection string / ID pairs.
• Logging into and out of one or more databases.
• Handling of user credentials with modifiable encryption.
• The ability to switch connection strings dynamically while the application is running.
• An easy-to-use, simple, high-level 
• A complete, extensible, lower-level interface for advanced usage.
• Integration with the standard cApplication class to provide full integration with the both the DataFlex Web and Windows application frameworks with less code.

You can use this link to access the online documentation for the DataFlex cConnection class.

Robust support for managed connections starts with the cConnection API, the DataFlex language and application frameworks, but the high-level support in the toolset, including the Studio, DataBase Explorer and others make them easier to understand, configure and use.

Once managed connections are set up using the Connection Manager, they are used throughout the Studio, from Workspace Dashboard, through Table Explorer and all the wizards. This complete integration streamlines development and allows developers to move from learning and exploration to complete implementation and deployment seamlessly.

Now we’ll look more closely at the Managed Connections architecture…

This is the core of understanding the power of managed connections; once we have an application that is compiled using managed connections, all that is necessary to deploy that workspace in any environment is to ensure that the database is available on the SQL Server and the Connection ID contains the information that identifies it.

Let’s use the Studio and our Cookbook workspace to illustrate some of the fundamental aspects of managed connections…

DEMONSTRATION

• We left with the Cookbook connection ID paired with the connection string pointing to the SQLEXPRESS server, the Cookbook database and Windows authentication (trusted connection).
  
• The configuration file reflects this status, but we’ll start with removing the trusted_connection setting. So I remove this line from Dfconnid.ini.
  
• Now, when we run the application, we are presented with the default login dialog. We’ll continue to use the Trusted Connection, but since we uncheck the “Remember…” option, and login
  
• The .ini file remains as it was, with no indication of what credentials to use when we run again. If our intent is to always present the login dialog, this is a good state. If we subsequently check the “Remember…” option, the .ini file is updated to always use Windows authentication.
• Next, we’ll experiment with SQL authentication, where we need user credentials defined in SQL Server.
• Using the SQL Server Management Studio, we’ll add user Cookbook (with a password) and make sure that user has read and write access to the Cookbook database.
  
• Then, in the DataFlex Studio, we’ll use the Connection Manager to edit the Cookbook connection and change it from using Windows authentication to the user credentials we just set up in SQL Server Management Studio. Using the Connection Manager allows us to easily test the new connection string.
  
• After we save the changes, we can set that the Cookbook ID now shows the UID of Cookbook, and a new setting of DFPWD201. This is the encrypted password that the tools will use to access the database. Note that the encryption algorithm is defined in the source code of the DataFlex tools. Developers have full control over the encryption used for applications, but not the tools (otherwise it would be impossible for developers to share workspaces).
  
• So, what happens now when we run the application? We get the default login dialog and the UID defined in the configuration file is shown, but we still need to complete the login. This time, we won’t “Remember…” the credentials and nothing is changed in the configuration file.
  
• Next, we will use the Remember feature
  
  
• And we see another new setting of PWD. This is the same password but encrypted using the logic in LoginEncryption.pkg. This is where developers can modify the default behavior and use whatever encryption logic they choose.
  
• All of this simply works because of four simple lines in the application. Inside the cApplication object, we declare the cConnection object and use the default login encryption and dialog. You can use the context help in the Studio to bring up the complete documentation for the cConnection class.
  
• In the next lesson we’ll look at security aspects of managed connections.