Connection Profiles

A connection profile describes a set of components, including peers, orderers, and certificate authorities in the Hyperledger Fabric blockchain network. It also contains channel and organization information relating to these components.

A connection profile should not be an exhaustive description of a network. It just needs to contain information sufficient for a gateway that is using it. In this section, we will observe a connection profile for test-network's Org1. Connection profiles can be either in the YAML or JSON format. We will use YAML, as it is easier to read.

The connection profile starts with two required fields: profile name and profile schema version (currently, only version 1.0 is supported).

name: test-network-org1
version: 1.0.0

There can also be an optional description field, e.g.:

description: "Connection profile for test-network's Org1"

Next, at least one organization and one peer are required to be listed in the corresponding sections. For the organization, you should specify the MSP ID, at least one peer to be used as a connection point, and optionally a list of associated certificate authorities.

organizations:
 Org1:
   mspid: Org1MSP    
   peers:
   - peer0.org1.example.com    
   certificateAuthorities:
   - ca.org1.example.com

The peer description should contain the peer’s IP address. You can also set some gRPC connection properties used for communication. If TLS is enabled in the network, the tlcCACerts field should be set to a root certificate in the TLS certificates chain. This can be done by passing a path to the .pem file in the path field, or by directly putting this file’s content in the pem field.

peers:
peer0.org1.example.com:
   url: grpc://localhost:7051
   tlsCACerts:
     pem:  |
          -----BEGIN CERTIFICATE-----     
          MIICJjCCAc2gAwIBAgIUARmPCbwbwiQhat/jbltlPz129+QwCgYIKoZIzj0EAwIw
          cDELMAkGA1UEBhMCVVMxFzAVBgNVBAgTDk5vcnRoIENhcm9saW5hMQ8wDQYDVQQH
          EwZEdXJoYW0xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh
          Lm9yZzEuZXhhbXBsZS5jb20wHhcNMjEwNTEzMTExOTAwWhcNMzYwNTA5MTExOTAw
          WjBwMQswCQYDVQQGEwJVUzEXMBUGA1UECBMOTm9ydGggQ2Fyb2xpbmExDzANBgNV
          BAcTBkR1cmhhbTEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMT
          Y2Eub3JnMS5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABN8G
          gAfoXNpx+hjeWReTkkdWkSl+3zvz6XjAQtC+/B1LheDQU9ktl3DyioxPe58Q/iQW
          TgU6GTiEM6EREFBmZ9ajRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAG
          AQH/AgEBMB0GA1UdDgQWBBRDea5Ucu6s7YLcuybYIpomf+4O9zAKBggqhkjOPQQD
          AgNHADBEAiAjA2aF7ON232Ga1gB0INQGuzftlKndVnADx0/LCtqdogIgV42QuRd5
          lwz4PuZovl+CSjp0/qsGfx9hM2CaqqzbxCY=
          -----END CERTIFICATE-----     

   grpcOptions:
     ssl-target-name-override: peer0.org1.example.com
     hostnameOverride: peer0.org1.example.com

The ssl-target-name-override option allows you to override the “real” hostname in order to avoid TLS issues. For instance, any Hyperledger Fabric peer node running inside the Docker container has a “fake” hostname (e.g., peer0.org1.example.com) in the certificate, while applications running on a host system will attempt to use localhost as the “real” hostname of a peer node. This mismatch causes TLS issues, unless the “real” hostname is overridden using the gRPC ssl-target-name-override option.

Other fields in a connection profile are optional. The most commonly used are orderers, certificateAuthorities, and channels. These sections describe the corresponding network components. For test-network, only the certificateAuthorities field is defined.

certificateAuthorities:
 ca.org1.example.com:
   url: http://localhost:7054
   caName: ca-org1
   tlsCACerts:    
     pem:
       - |
          -----BEGIN CERTIFICATE-----     
          MIICJjCCAc2gAwIBAgIUARmPCbwbwiQhat/jbltlPz129+QwCgYIKoZIzj0EAwIw
          cDELMAkGA1UEBhMCVVMxFzAVBgNVBAgTDk5vcnRoIENhcm9saW5hMQ8wDQYDVQQH
          EwZEdXJoYW0xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHDAaBgNVBAMTE2Nh
          Lm9yZzEuZXhhbXBsZS5jb20wHhcNMjEwNTEzMTExOTAwWhcNMzYwNTA5MTExOTAw
          WjBwMQswCQYDVQQGEwJVUzEXMBUGA1UECBMOTm9ydGggQ2Fyb2xpbmExDzANBgNV
          BAcTBkR1cmhhbTEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEcMBoGA1UEAxMT
          Y2Eub3JnMS5leGFtcGxlLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABN8G
          gAfoXNpx+hjeWReTkkdWkSl+3zvz6XjAQtC+/B1LheDQU9ktl3DyioxPe58Q/iQW
          TgU6GTiEM6EREFBmZ9ajRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAG
          AQH/AgEBMB0GA1UdDgQWBBRDea5Ucu6s7YLcuybYIpomf+4O9zAKBggqhkjOPQQD
          AgNHADBEAiAjA2aF7ON232Ga1gB0INQGuzftlKndVnADx0/LCtqdogIgV42QuRd5
          lwz4PuZovl+CSjp0/qsGfx9hM2CaqqzbxCY=
          -----END CERTIFICATE-----

   httpOptions:
     verify: false

A complete connection profile can be found in the test-network/organizations/peerOrganizations/org1.example.com/connection-org1.yaml file in the fabric-samples repository. The same connection profile in the JSON format can be found in connection-org1.json. To learn more about the connection profile structure, check out the official documentation.

Now, let’s create the submitTransaction.js file in the applications/balance_transfer folder. In this file, let’s initialize the FileSystemWallet and Gateway objects.

const { Wallets, Gateway } = require('fabric-network'); 

async function main() {
   const gateway = new Gateway();
   const wallet = await Wallets.newFileSystemWallet('./wallet');
}