GBG Developers

Guides   |   Working with the SDK: First Steps

Working with the SDK: First Steps

Prior to working with the SDK, a GBG Identity Solution account is required. To set up the Identity Solution account see the Getting Started guides. You’ll be set up with an account which you can access using Delegated Authentication (OAuth OpenID Connect) or with a Pre-generated Token.


Delegated Authentication involves sending a secure HTTP request to your OAuth Identity Provider (such as Microsoft or Amazon Web Services) and receiving back an Identity Provider (IDP) access token. The token can later be exchanged (using an SDK function call, or another HTTP request) for a GBG access token whenever the user wishes to use the Identity Solution. The access token eventually expires and then another token can be requested by the user or the software.

The Pre-generated token is provided by GBG and can be exchanged for a GBG access token by sending a request to the GBG service.

You’ll also receive an initial Journey Identifier which defines which databases and verification procedures you wish to use to meet business or legal requirements. Additional Journey Identifiers can be created and profiles modified as needed.

If you’re planning to use the Web SDK, then credentials to download the SDK will also be supplied.

Once you have the account and SDK, proceed to set up your development environment. The example in this guide will assume Microsoft Visual Code is being used.

To open the Web SDK with Visual Code, right-click on the index.code-workspace file and select Open With Code.

The left side Visual Code Explorer pane will show several top-level folders. Within the src sub-folder there are three folders; docs, sdk and test-harness.

The docs folder contain documentation in Markdown syntax, which appears formatted when opened in Visual Code.

Underlying the SDK are HTTP requests and responses. If during software development you need to troubleshoot SDK interactions, a very quick way to see what occurred is to examine the HTTP request and response. To do this the Chrome Developer Tools network view can be used.

All of the services can be coded in JavaScript using this very simple syntax where the placeholder ActivityName is replaced with a name such as AddressLookup or PeopleVerify:

function doActivity () {
    return window.sdkInstance.performActivity({
        activity: GBG.IDaaS.Activities.ActivityName
    })
        .then((obj) => {
             console.log(obj);
		console.log("completed activity"));
        })
}

 

Passing Parameters into Activities

Note that some of the activities may require parameters to function. These are defined in the sdk\interfaces\activities.ts file. For example, the Facematch activity accepts the following parameter, verificationID:

/**
 * Parameters for the Face Match activity.
 *
 * @public
 */
export interface IFaceMatchParameters extends IImageCaptureParameters {
	/**
	 * The identifier of the verification that was recently checked.
	 */
	verificationId: GUID;
}


The verificationID parameter in the case of Facematch comes from the result of a previous Document Capture activity that was executed.

 

Templates

Templates are used to influence the content and view of each activity. For instance it is possibly to apply HTML for various fields on the display, perform custom field validation or to modify text for (say) a different language. It is optional to modify the existing template behaviour. For an example of how to do this, see the Configure the SDK and Obtain GBG Access Token guide. The complete syntax for templates is available in the docs/templates.md file in the SDK.