Hello @VIJAY KUNWAR,
You've really got two different questions here. The first seems to be how do you use the SharePoint connector in general while the second is how do you set up Delegated access authentication.
Let's start with the first question about using the connector. From the start, you should be able to execute any action that requires the SharePoint site ID because the site ID can be specified as either the user-friendly FQDN of the site (ex. contoso.sharepoint.com) or the sites full ID which is a composite of the following values:
As for the other values (Drive ID, File ID, etc), it's a matter of calling various actions on the connector and then iterating over the response data. For example, the get a list of Drive ID's of your root SharePoint site you could call the Get Root Site action followed by the Get All Drives action. Alternatively, you could just call Get All Drives directly, or even Get Default Drive Details if there's a single drive associated with the site, since you already know the FQDN of your SharePoint site.
Once you have the ID of the specific drive associated with your SharePoint site, you'll want to call Get Root Folder ID for the specific SharePoint site and drive. This will give you the top-level folder ID for the drive. From there, you can call Get Drive Items to get a collection of all the contents in that specific folder. Then you would iterate over that collection and drill into any other child folders you may be interested in.
On to the second question, authentication. There are two token types available when using the Microsoft Graph - Authentication VBO. They are Application Access and Delegated Access. Application Access tends to be the easier method and is meant for service-to-service or machine-to-machine communication. It's a similar idea to what are known as Service Accounts on Windows.
Delegated Access, on the other hand, is where you're requesting access on behalf of a specific user account. In other words, your digital worker is going to work on behalf of a specific user (ex John Doe). If you look through the Graph API reference, you'll see many examples of actions that are only supported with Delegated Access. To use Delegated Access you must provide an OAuth2 Client ID and Client Secret as well as the Active Directory Username and Password of the user account you are trying to work on behalf of.
Of course you also have to pass in your Microsoft 365 tenant ID. All of this information can be collected from the Microsoft 365 AD console. If you don't have direct access to that, you'll have to request the information from your IT team. This includes having them set up an application definition for you in AD. Below are some screenshots of a test application definition I have created in my Azure sandbox along with some of the Graph API permissions I applied to that application so that it could work with my SharePoint sites.
Hope this helps. If not, let me know what specific questions you have.
Cheers,
------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------
You've really got two different questions here. The first seems to be how do you use the SharePoint connector in general while the second is how do you set up Delegated access authentication.
Let's start with the first question about using the connector. From the start, you should be able to execute any action that requires the SharePoint site ID because the site ID can be specified as either the user-friendly FQDN of the site (ex. contoso.sharepoint.com) or the sites full ID which is a composite of the following values:
- Site collection hostname (contoso.sharepoint.com)
- Site collection unique ID (GUID)
- Site unique ID (GUID)
As for the other values (Drive ID, File ID, etc), it's a matter of calling various actions on the connector and then iterating over the response data. For example, the get a list of Drive ID's of your root SharePoint site you could call the Get Root Site action followed by the Get All Drives action. Alternatively, you could just call Get All Drives directly, or even Get Default Drive Details if there's a single drive associated with the site, since you already know the FQDN of your SharePoint site.
Once you have the ID of the specific drive associated with your SharePoint site, you'll want to call Get Root Folder ID for the specific SharePoint site and drive. This will give you the top-level folder ID for the drive. From there, you can call Get Drive Items to get a collection of all the contents in that specific folder. Then you would iterate over that collection and drill into any other child folders you may be interested in.
On to the second question, authentication. There are two token types available when using the Microsoft Graph - Authentication VBO. They are Application Access and Delegated Access. Application Access tends to be the easier method and is meant for service-to-service or machine-to-machine communication. It's a similar idea to what are known as Service Accounts on Windows.
Delegated Access, on the other hand, is where you're requesting access on behalf of a specific user account. In other words, your digital worker is going to work on behalf of a specific user (ex John Doe). If you look through the Graph API reference, you'll see many examples of actions that are only supported with Delegated Access. To use Delegated Access you must provide an OAuth2 Client ID and Client Secret as well as the Active Directory Username and Password of the user account you are trying to work on behalf of.
Of course you also have to pass in your Microsoft 365 tenant ID. All of this information can be collected from the Microsoft 365 AD console. If you don't have direct access to that, you'll have to request the information from your IT team. This includes having them set up an application definition for you in AD. Below are some screenshots of a test application definition I have created in my Azure sandbox along with some of the Graph API permissions I applied to that application so that it could work with my SharePoint sites.
Hope this helps. If not, let me know what specific questions you have.
Cheers,
------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------
Hello @VIJAY KUNWAR,
If you're trying to get a delegated user token then it must be for a user that's defined in the Azure AD. Microsoft Graph is based on Azure. All of the permissions are governed by the associated Azure AD of your specific tenant. Microsoft Graph is not an API that can be used with traditional/legacy SharePoint on-prem deployments.
I don't understand your second question. I laid out, in my previous response, the various actions that can be used for collecting that information. When you call those actions you'll receive output data from Graph, typically in the form of a Blue Prism Collection or a JSON blob (aka Text). As an example, if I get my auth token and then I call the action Get Root Site it will return a Collection of data containing information about my root SharePoint site as pictured below:
As for your third question, Microsoft has made it clear that the Graph API is their API of choice, moving forward, for working with Azure/Microsoft 365 services including Excel, Outlook, Teams, SharePoint, etc. It's not a complete API yet though. Microsoft still haven't added support for Word, PowerPoint, Visio, etc yet.
If you already have code in place that's getting a token for you then you should be able to pass that token into the various actions on the SharePoint connector, assuming you've granted the appropriate SharePoint permissions to the the specific application definition you're Client ID and Client Secret are tied to. If all you're using to get the token is Client ID and Client Secret then what you're getting is an Application Access Token (yes this is a type of Bearer token).
Cheers,
------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------
If you're trying to get a delegated user token then it must be for a user that's defined in the Azure AD. Microsoft Graph is based on Azure. All of the permissions are governed by the associated Azure AD of your specific tenant. Microsoft Graph is not an API that can be used with traditional/legacy SharePoint on-prem deployments.
I don't understand your second question. I laid out, in my previous response, the various actions that can be used for collecting that information. When you call those actions you'll receive output data from Graph, typically in the form of a Blue Prism Collection or a JSON blob (aka Text). As an example, if I get my auth token and then I call the action Get Root Site it will return a Collection of data containing information about my root SharePoint site as pictured below:
As for your third question, Microsoft has made it clear that the Graph API is their API of choice, moving forward, for working with Azure/Microsoft 365 services including Excel, Outlook, Teams, SharePoint, etc. It's not a complete API yet though. Microsoft still haven't added support for Word, PowerPoint, Visio, etc yet.
If you already have code in place that's getting a token for you then you should be able to pass that token into the various actions on the SharePoint connector, assuming you've granted the appropriate SharePoint permissions to the the specific application definition you're Client ID and Client Secret are tied to. If all you're using to get the token is Client ID and Client Secret then what you're getting is an Application Access Token (yes this is a type of Bearer token).
Cheers,
------------------------------
Eric Wilson
Director, Integrations and Enablement
Blue Prism Digital Exchange
------------------------------
