powerobjects: Visual Studio Console Application Development and Usage

[Blog bot]

Источник: https://www.powerobjects.com/2018/03...lopment-usage/
==============


In this blog, we will describe how the native client application in Dynamics 365 for Finance and Operations can be created to test custom services. When we talk about services, there are two types:

• Custom services
• OData services

For any service we create in Dynamics 365 for Finance and Operations, we need to have authentications.

Here are the two types of authentications that are supported:

• Authorization Code Grant Flow: In this Authentication type, Azure Active Directory (Azure AD) uses OAuth 2.0 to enable users to authorize access to web applications and web APIs in a user’s Azure AD tenant. This guide is language independent and describes how to send and receive HTTP messages without using any of our open-source libraries. For more details, click this link.
• Service to service calls using client credentials (shared secret or certificate): For this Authentication type, the OAuth 2.0 Client Credentials Grant Flow permits a web service (confidential client) to use its own credentials instead of impersonating a user, to authenticate when calling another web service. In this scenario, the client is typically a middle-tier web service, a daemon service, or web site. For a higher level of assurance, Azure AD also allows the calling service to use a certificate (instead of a shared secret) as a credential. For more details click this link.

When testing Custom services using client applications, Microsoft Azure Active Directory (AAD) supports these two kinds of applications:

• Native client application: This application uses a user name and password for authentication and authorization.
• Web application (Confidential client): A confidential client is an application that can keep a client password confidential to the world. The authorization server assigned this client password to the client application.

The diagram below describes how authorization must be configured.



Console Application

Console application (app) is a program developed in Visual Studio which accepts input parameter, calls the required service, runs business logic and sends output to the console, this console is known as the command prompt.

Console Application Development Steps

The console app development can be divided into three main parts: register the native application in Azure, register the application in Dynamics 365 for Finance and Operations, and Visual Studio app development. Here are the steps you need to take:

Register the Native application in Azure

1. Sign in to the Azure Portal with your account that has access to Dynamics 365 for Finance and Operations.

2. Select Azure Active Directory on the left-hand side and App registrations then click New application registration.

3. Enter app name, select the application type Web app/API, enter your organization’s URL in Sign-on URL (example: https://demoXXXaos.cloudax.dynamics.com) and then click Create.

4. Create a new key for the registered app. Enter a Key description, Duration, and click Save. It will automatically generate a key value that you will need to save so that we can use it later in the Visual Studio project. Also, save the Application ID for later.





5. Now add Required permissions. Select an API: “Microsoft Dynamics ERP.”



6. Now select the permissions, check all 3 delegated permissions then click Select. Click Done.





7. You can verify the delegated permissions on the main dashboard.





Register the application in Dynamics 365 for Finance and Operations

1. Open your Dynamics 365 for Finance and Operations, Go to System administration > Setup > Azure Active Directory applications, click the New button to create a new record.



2. Enter your Azure Application Id into the Client Id field. Enter your Azure Application name into the name field. Select Admin is in User ID field.



3. Click Save and it will be created.

Visual Studio app development

1. Run Visual Studio and go to File > New Project. Go to Templates > Visual C#. Navigate to Windows Classic Desktop on the left side of the screen and select Console App on the right side. Enter the name of the project and click OK.



2. Right click on Visual Studio project and select Add > Service reference.



3. In the new window, enter the URL to WSDL of Dynamics 365 for Finance and Operations any service (Standard or Customized).

The URL will be like this: https://{AOSANAME}.cloudax.dynamics.com/soap/services/



4. Enter “Service Group name” in the Namespace field. Click OK and Visual Studio will generate proxy classes for the specified services endpoint.

5. Right click on Visual Studio project and select Manage NuGet Packages.



6. Visual Studio will find the Microsoft library: Microsoft.IdentityModel.Clients.ActiveDirectory. Select this library and click the Install button on right side of this window. Click Ok to continue.



7. Expand the project and click on Program.cs.



8. The first method will be to format SOAP service string.



9. Next requirement is to get the service binding.

This code first creates an instance of BasicHttpBinding, then reads the configuration parameters from the config file, and it creates an instance of RealtimeServiceClient which is then used to make actual calls.

BasicHttpbinding is a binding that a Windows Communication Foundation (WCF) service can use to configure and expose endpoints that are able to communicate with ASMX-based Web services and clients and other services.

Best practice when dealing with the Key (password) is that the password is stored in unencrypted form in the configuration file, it is then encrypted in the code and eventually used in constructor of RealtimeServiceClient (that object requires an encrypted password). In your real applications you should have a dedicated application/process which will first encrypt the password acquired from Azure Active Directory, and only then stored in the configuration file. This way, even if the key is stolen an attacker will not be able to use/decrypt it on a different machine. So, do not save your secrets unprotected.



10. Now in Main method of the class, the first web authentication code needs to be written.

• aosUri – This will Dynamics 365 for Finance and Operations AOS name.
  Example: https://{AOSNAME}.cloudax.dynamics.com/
• activeDirectoryTenant – The Azure AD directory tenant used with the Dynamics 365 for Finance and Operations server.
  Example: https://login.windows.net/{COMPANY_DOMAIN}
• activeDirectoryClientAppId – The client ID was obtained when the Azure App registration was done.
• activeDirectoryClientAppSecret – This is the secret key which was generated during the Azure active directory registration.
• activeDirectoryResource – This will be the Dynamics 365 for Finance and Operations AOS URL. Note: Do not end this field with a forward slash character (/).

11. Now you must pass the service you want to consume, and then binding needs to be done.



12. Once binding is done, call the contract class for the service to pass parameters.



13. Finally write the code and read the result in the console line. The code written below calls the main entry point method of the service where the business logic is written and runs the method with the parameters passed above. The result is displayed on the command prompt screen.



Console Application Usage

A developer can create a console app to do the testing of customized services or standard services created in Dynamics 365 for Finance and Operations.

The console app can also be used as a proof-of-concept demonstration of functionality that will be later incorporated into a Windows desktop application or Universal Windows Platform App.

Conclusion

In this blog we learned how to create a Console application by creating connections between Azure, Dynamics 365 for Finance and Operations, and Visual studio. Similarly, in Dynamics 365 for Finance and Operations we have few more ways using in which integrations can be done. Here are a few listed below:

• SOAP: This is an XML based protocol for accessing Web Services and it synchronously exchanges data. It supports HTTPS and XML based integrations.
• REST (Representational State Transfer): This is same as SOAP but is lightweight and does not require any XML parsing. It supports HTTPS and JSON based integrations.
• ODATA (Open Data): This is a standard protocol for creating and consuming data, this also follows synchronous mode of integration. It supports HTTPS, JSON and XML based integrations.|
• CDS (Common Data services): This integrator lets you build an end-to-end view of business data by making Dynamics 365 for Finance and Operation data available in CDS from various data sources.

For more information about integrations in Dynamics 365 for Finance and Operations, here are a couple of useful links:

Data Management & Integration Using Data Entities – Part 1

Data Management and Integration Using Data Entities – Part 2

Happy Dynamics 365’ing!



Источник: https://www.powerobjects.com/2018/03...lopment-usage/