Unfortunately the official documentation https://social.technet.microsoft.com/wiki/contents/articles/1664.expose-biztalk-applications-on-the-cloud-using-appfabric-connect-for-services.aspx#Exposing_the_BizTalk_Orchestration_as_a_Service_on_the_Cloud
is not sufficient to accomplish the exposing of a BizTalk WCF or Rest endpoint via an Azure Service Bus relay.

If you are trying to do that and struggling with error like
The type 'Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' registered for extension 'transportClientEndpointBehavior' could not be loaded.
the following steps might be helpful for you:

1. If you use Service Bus Namespace as described in the official documentation you'll need to install additional tool named "Azure Service Bus Explorer" to be able to see the automatically created relay. To avoid this issue, simple create a Relay service in Azure rather then creating Service Bus Namespace. Basically Service Bus Namespace and Relay services are providing the same features for relays, but the Relay service is specialized for Relay feature only, while Service Bus Namespace is providing further features like Queues and Topics.

2. After publishing a WCF service by using "BizTalk WCF Service Publishing Wizard" as described in the official documentation (or similar way if you published a Rest service) you need to correct the version of the assembly Microsoft.ServiceBus.dll delivered by wizard. Otherwise you'll get the error "'transportClientEndpointBehavior' could not be loaded." mentioned above, when trying to call the WCF/Rest endpoint locally on the BizTalk. This error is preventing the web service to create required Relay items in the Azure (which is done in the service start), so you'll not see any services there until you fix this error.
   To get rid of this error, go to the IIS folder holding the web application created by WCF Publishing wizard (you can find the path of the location in the completion view in the wizard, for usually something like "C:\inetpub\wwwroot\YourWebAppName"), navigate to the subfolder App_Data/bin and finally replace the assembly Microsoft.ServiceBus.dll in this folder with the latest version of this assembly which can be downloaded from https://www.nuget.org/packages/WindowsAzure.ServiceBus.

3. Use VS command prompt with elevated permissions to register the new version of "Microsoft.Servicebus.dll" into GAC:
   gacutil -i C:\inetpub\wwwroot\YourWebAppName\App_Data\bin\Microsoft.ServiceBus.dll

4. Create new application pool in IIS Management console. You are free to use any allowed name for this app pool. As identity of the new pool use the same account used by BizTalkServerIsolatedHost.

5. Use IIS management console to assign the newly created app pool to your web application previously created by "BizTalk WCF Service Publishing Wizard".

6. If you don't want to use Windows App Fabric as described in the official documentation to get the web app automatically started, you can simply activate the "Application Initialization" feature in the Windows Server features:
   Server Management -> Manage -> Add Roles and Features -> Activate Web Server (IIS) – Web Server – Application Development – Application Initializiation
   Afterward add the following element to the web.config file of your WCF/Rest web application.

<system.webServer>
     <applicationInitialization doAppInitAfterRestart="true">
       <add initializationPage="/Service1.svc" />
     </applicationInitialization>
</system.webServer>

You can find here more details regarding the settings required to have the web application always running. This is required, since the relay in Azure will exist only if the web app is running.

7. Use IISRESET from elevated command promt to restart the IIS.

Having all this done, you should be able to open the your BizTalk Endpoint in the browser (localy, on BizTalk server) without any errors.
If you take a look into Azure Portal (or in Azure Service Bus Explorer), you'll see new WCF Relay item automatically created in your Azure Relay Service or Service Bus Namespace Service.

Now to get the BizTalk WCF or Rest endpoint called from anywhere you can use the Uri of the created Azure relay, something like that:
https://yourrelay.servicebus.windows.net/YourWebAppName/Service1.svc/YourServiceOperation
"YourServiceOperation" needs to be configured in the adapter setting of the BizTalk receive Location assigned to your IIS web application.

You need to put following HTTP Header to your request for authentication purposes:
Authorization: SharedAccessSignature [sasToken]
where [sasToken] is to be replaced with a time limited Shared Access Signature token, generated from the Shared Access Policy name and key value for particular resource Uri.
Example:

Authorization: SharedAccessSignature sr=https%3a%2f%2fyourAzureRelay.servicebus.windows.net%2fyourWcfRelay&sig=ZYJkLRqivWHsHxPIUUlUL5LXIEIEFRoEVyDVU%2bxFljs%3d&se=1612453185&skn=yourSasPolicyName

Here is sample code showing how to generate a Sas Token with expiration time 1 hour:

string CreateSASToken(string resourceUri, string keyName, string keyValue)
{
    TimeSpan sinceEpoch = DateTime.UtcNow - new DateTime(1970, 1, 1);
    var expiry =  Convert.ToString((int)sinceEpoch.TotalSeconds + 3600);

    string stringToSign = HttpUtility.UrlEncode(resourceUri) + "\n" + expiry;
    HMACSHA256 hmac = new HMACSHA256(Encoding.UTF8.GetBytes(keyValue));

    var signature = Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes(stringToSign)));
    var sasToken = String.Format(CultureInfo.InvariantCulture, "SharedAccessSignature sr={0}&sig={1}&se={2}&skn={3}",
                HttpUtility.UrlEncode(resourceUri), HttpUtility.UrlEncode(signature), expiry, keyName);
   return sasToken;
}

where:
resourceUri = "https://yourAzureRelay.servicebus.windows.net/yourWcfRelay";

keyName = "your SAS Policy name created for Relay in Azure Portal"

keyValue = "value of the primary or secondary key for the SAS Policy, which is automaticaly generated in Azure Portal on SAS Token creation"

You can use Azure Portal to create Shared Access policy for your Relay or Service Bus Namespace.
Consider that a policy used by the BizTalk Endpoint consumer should be permitted for Sending messages only.

And finally, here is sample code how to call Azure Relay endpoint by using HttpClient:

using(var httpClient = new HttpClient())
{
    var url = string.Format("{0}", RelayAddress);
                                         httpClient.DefaultRequestHeaders.TryAddWithoutValidation("Authorization",    sasToken);
                        
    httpClient.DefaultRequestHeaders.TryAddWithoutValidation("Content-Type",   "application/json");
   
   var content = new StringContent("{'Property': 'Value'}");
   var response = await httpClient.PostAsync(resourceUri, content);
   var responseText = await response.Content.ReadAsStringAsync();

}

The approach described worked for me fine on both, BizTalk Server 2016 and BizTalk 2020.

Edit:
If a proxy server is required to be configured on your BizTalk server for outgoing HTTP connections, you will determine that the WCF-WebHttp Receive Adapter used in your Receive location generated by WCF Publisher Wizard doesn't provide configuration option for that.
The easiest way to get Proxy Server configured is to insert the following configuration section to end of the web.config file of your IIS web application:

  ...
  <system.net>
    <defaultProxy>
      <proxy proxyaddress="http://yourProxyServer:port" />
    </defaultProxy>
  </system.net>
</configuration>

Consider "proxyaddress" to be written in lowercase. Trying to apply camelcase ("proxyAddress" what I did) will not work here. Instead of getting an error saying "invalid property" or similar, the proxy setting will simply not be applied.

Theoretically, it should be also possible to apply the proxy server on the webHttpRelayBinding configuration element by using proxyAddress attribute like here:

...
<bindings>
      <webHttpRelayBinding>
        <!-- For some reasons, this doesn't work -->
        <binding name="RelayEndpointConfig" useDefaultWebProxy="false" proxyAddress="http://yourProxyServer:port"> 
          <security relayClientAuthenticationType="RelayAccessToken" mode="Transport" />
        </binding>
      </webHttpRelayBinding>
    </bindings>
...

For some reasons this didn't work for me. The proxy server defined here, was simply ignored. But in contrast to the camelcase behavior mentioned above for "proxyaddress" attribute in "defaultProxy" element, here you'll get an "invalid property" error if you don't use camelcase and write "proxyaddress" instead of "proxyAddress".

To configure 2-way certificate authentication in the MQSC adapter used in BizTalk receive location to retrieve messages from an IBM MQ Queue you’ll need at least 2 certificate sets:

1. Server Certificates set

The server certificates set will be usually provided by the remote party responsible for the IBM MQ Server. This certificates set consists at least of one Server/Client authentication certificate and possible one or more Root CA certificates (if not included in the Server/Client certificate) used to build valid certification path for the Server/Client certificate.
This certificate set must be installed in two different locations on the BizTalk server to make the BizTalk MQSC Adapter able to use it:

1. Installation of Server certificates in IBM Key Database

a) Use the “IBM Key Management” Tool strmqikm.exe (can be found in the IBM MQ Client installation folder (for usually here C:\Program Files\IBM\WebSphere MQ\bin64) to create a new IBM key database as described here.

b) Use “Add…” button under “Signer Certificates” in the “IBM Key Management” GUI to add all Server certificates to the IBM key database:

Please note, here you can use any name when asked to enter certificates label.

2. Installation of Server certificates in Windows User Certificate store

In addition to the installation of the Server certificates in the IBM Key database certificate storage, you’ll need to install the same certificates in the windows User Certificate storage on the BizTalk server. To accomplish this, you’ll need to login to the BizTalk server with the service account used by BizTalk Host Instance the MQSC adapter based Receive Location is assigned to.

a) Login to the BizTalk Server with the credentials of the service account used by BizTalk host instance assigned to the MQSC Adapter based receive location you want to get running.

b) Open User certificates storage from command prompt by using the command certmgr.msc

c) Use the “Import…” option to import all Server certificates. The Server/Client authentication certificate should be imported to the “Personal” storage. All other Root CA certificates are to be imported to the “Trusted Root Certification Authorities” storage:

2. Client Certificates set

The Client certificates set will be usually provided by the party responsible for the network/domain where the BizTalk Server is hosted. Similar to the Server certificate set, the Client certificate set also consists at least of one Server/Client authentication certificate and possible one or more Root CA certificates (if not included in the Server/Client certificate) used to build valid certification path for the Server/Client certificate. The subject of this certificate should be FQDN of the BizTalk Server.

1. Create Certificate Signing Request

Use the menu option “Create -> New Certificate Request …” in the “IBM Key Management” tool (installed with the IBM MQ Client installation under C:\Program Files\IBM\WebSphere MQ\bin64\strmqikm.exe) on the BizTalk Server to generate Certificate Signing Request (CSR) for the BizTalk Server machine:

In the field “Key Label” you can use any name to describe the certificate. The Certificate Request will appear under this label in the list of certificate requests in the IBM Key Management tool.
I have used “Key Size” 1024 and “Signature algorithm” SHA384WithRSA. Important is to set “Common Name” to FQDN name of the BizTalk Server (if not automatically filled).
You should also fill out further fields like organization, country etc. to make the certificate more transparent later.

2. Send CSR file to system admin

Provide the generated CSR file to the system administrator of the BizTalk Server domain to get valid Client certificates set.
Please note, the IBM Key Management tool creates CSR file in *.arm format which is not supported by Windows tools for certificate generation. If your system administrator requires *.der format you can use the function “Extract …” to create CSR export in this format:

For more details regarding how to send third party certificate signing request on windows see the following links:
https://www.ibm.com/support/pages/request-contains-no-certificate-template-information-when-signing-thirdpartycertificatetool-csr
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certreq_1

The certificate template to be used is by system administrator is “Computer”, “Client Authentication, Server Authentication”:

3. Import Certificate retreived from system admin

Once the system administrator has provided the Client certificate set to you, you’ll need to use the action “Receive …” under “Personal Certificates” in the “IBM Key Management” GUI to import the certificate retrieved from the system administrator:

4. Import Root CA certificates too (onl if the imported certificate is not valid)

If the certificate doesn’t contain all Root CA certificates building the full certification path (you can check this by using “Validate” action under “Personal Certificates”), you’ll need to import CA Root certificates manually by using “Add …” action under “Signer Certificates” in the “IBM Key Management” GUI.
IMPORTANT: The label of the Client Certificate must be built from the fix prefix “ibmwebspheremq” followed by the name of the service account the BizTalk Host Instance is running with in lowercase. I.e. “ibmwebspheremqbtssvcaccount” without quotes, when the name of the account used by BizTalk Host instance is “BtsSvcAccount”.

5. Provide public part of certificate to the remote party

Finally, extract the public key and provide it to the remote party to make them able to prepare the IBM MQ Server for the communication with the BizTalk server.
For more details how to extract certificate public key see here.

4. Configure BizTalk MQSCA Adapter for Receive Location

Finally you can configure the BizTalk MQSC Adapter in the Receive Location.
The minimal set of the mandatory settings required for MQSC Adapter configuration even if you don’t want to configure two-way certificate based authentication are:
• Connection name (IP address or host name of the IBM MQ Server)
• Port number of the IBM MQ
• Channel name
• Name of the Queue Manager
• Name of the Queue
All those values provided to you by the remote party which is hosting the IBM MQ Server, must be entered in the MQSC Adapter settings view.
In addition to those parameters remote party must provide to you a value for the Adapter setting “SSL Cipher Specification” (i.e. something like ECDHE_RSA_AES_256_CBC_SHA384) which is also to be configured in the BizTalk MQSC adapter settings of the receive location.
The last required setting is “SSL Key Repository Location” which is actually path of the IBM Key database created in the step 1.1.a of this description.
Please note, the name of the IBM Key database file must not contain file extension (i.e. if the Key DB name is C:\ProgramData\IBM\MQ\key.kdb the value to enter in the “SSL Key Repository Location” is “C:\ProgramData\IBM\MQ\key”.

I used BizTalk Server 2013 R2, but the is probably valid for other BizTalk versions too.

Update:
While trying to get the MQSC adapter based Receive Location in the production environment running, we detected some more issues and additional configuration steps were required.

1. On the MQ Server side the admins needed to add following setting:
   CHANNELS:
   PasswordProtection=OPTIONAL
2. In the MQSC BizTalk adapter settings we entered the value "mqm" as "User Id".
3. On the BizTalk server, in the file mqclient.ini (C:\Program Files (x86)\IBM\WebSphere MQ\mqclient.ini) we added folloowing configuration:
   SSL:
   OCSPAuthentication=OPTIONAL
   OCSPCheckExtensions=NO
   CDPCheckExtensions=NO
   CHANNELS:
   PasswordProtection=OPTIONAL
   MQCSP.AuthenticationType=MQCSP_AUTH_NONE
4. We added following environment variable to the BizTalk machine:
   MQCCSID = 1208
   Please remark, all those changes were not required in all environments we have.