Showing posts with label Azure Service Bus Queue. Show all posts
Showing posts with label Azure Service Bus Queue. Show all posts

Monday, August 19, 2019

Azure Message or Azure Event

A message generally contains the data itself, not just a reference (like an ID or URL) to data. Sending the data as part of the datagram is less brittle than sending a reference. The messaging architecture guarantees delivery of the message, and because no additional lookups are required, the message is reliably handled. However, the sending application needs to know exactly what data to include to avoid sending too much data, which requires the receiving component to do unnecessary work. In this sense, the sender and receiver of a message are often coupled by a strict data contract.
In a pizza company, when a pizza order is entered, the company would likely use messages. The web front end or mobile app would send a message to the back-end processing components. In the back end, steps like routing to the store near the customer and charging the credit card would take place.

Events

An event triggers a notification that something has occurred. Events are "lighter" than messages and are most often used for broadcast communications.
Events have the following characteristics:
  • The event may be sent to multiple receivers, or to none at all
  • Events are often intended to "fan out," or have a large number of subscribers for each publisher
  • The publisher of the event has no expectation about the action a receiving component takes
The pizza chain would likely use events for notifications to users about status changes. Status change events could be sent to Azure Event Grid, then on to Azure Functions, and to Azure Notification Hubs for a completely serverless solution.
This difference between events and messages is fundamental because communications platforms are generally designed to handle one or the other. Service Bus is designed to handle messages. If you want to send events, you would likely choose Event Grid.
Azure also has Azure Event Hubs, but it is most often used for a specific type of high-flow stream of communications used for analytics. For example, if we had networked sensors on our pizza ovens, we could use Event Hubs coupled with Azure Stream Analytics to watch for patterns in the temperature changes that might indicate an unwanted fire or component wear.

How to choose a communications technology

Consider the following questions:
  1. Is the communication an event? If so, consider using Event Grid or Event Hubs.
  2. Should a single message be delivered to more than one destination? If so, use a Service Bus topic. Otherwise, use a queue.
If you decide that you need a queue:

Choose Service Bus queues if:

  • You need an at-most-once delivery guarantee
  • You need a FIFO guarantee
  • You need to group messages into transactions
  • You want to receive messages without polling the queue
  • You need to provide role-based access to the queues
  • You need to handle messages larger than 64 KB but smaller than 256 KB
  • Your queue size will not grow larger than 80 GB
  • You would like to be able to publish and consume batches of messages

Choose queue storage if:

  • You need a simple queue with no particular additional requirements
  • You need an audit trail of all messages that pass through the queue
  • You expect the queue to exceed 80 GB in size
  • You want to track progress for processing a message inside of the queue
Although the components of a distributed application can communicate directly, you can often increase the reliability of that communication by using an intermediate communication platform such as Azure Service Bus or Azure Event Grid.
Event Grid is designed for events, which notify recipients only of an event and do not contain the raw data associated with that event. Azure Event Hubs is designed for high-flow analytics types of events. Azure Service Bus and storage queues are for messages, which can be used for binding the core pieces of any application workflow.
If your requirements are simple, if you want to send each message to only one destination, or if you want to write code as quickly as possible, a storage queue may be the best option. Otherwise, Service Bus queues provide many more options and flexibility.
If you want to send messages to multiple subscribers, use a Service Bus topic.

Azure Queue Storage vs Azure Service Bus Queue vs Azure Service Bus Topic

What is Azure Queue Storage?

Queue storage is a service that uses Azure Storage to store large numbers of messages that can be securely accessed from anywhere in the world using a simple REST-based interface. Queues can contain millions of messages, limited only by the capacity of the storage account that owns it.

What is Azure Service Bus Queues?

Service Bus is a message broker system intended for enterprise applications. These apps often utilize multiple communication protocols, have different data contracts, higher security requirements, and can include both cloud and on-premises services. Service Bus is built on top of a dedicated messaging infrastructure designed for exactly these scenarios.
Both of these services are based on the idea of a "queue" which holds sent messages until the target is ready to receive them.
What are Azure Service Bus Topics?
Azure Service Bus topics are like queues, but can have multiple subscribers. When a message is sent to a topic instead of a queue multiple components can be triggered to do their work. Imagine in a music sharing application, a user listening to a song. The mobile app might send a message to the "Listened" topic. That topic will have a subscription for "UpdateUserListenHistory" and a different subscription for "UpdateArtistsFanList". Each of those functions is handled by a different component that receives its own copy of the message.
Internally, topics use queues. When you post to a topic, the message is copied and dropped into the queue for each subscription. The queue means that the message copy will stay around to be processed by each subscription branch even if the component processing that subscription is too busy to keep up.

Which one to choose?

Choose Service Bus Topics if

  • you need multiple receivers to handle each message

Choose Service Bus queues if:

  • You need an At-Most-Once delivery guarantee.
  • You need a FIFO guarantee.
  • You need to group messages into transactions.
  • You want to receive messages without polling the queue.
  • You need to provide a role-based access model to the queues.
  • You need to handle messages larger than 64 KB but less than 256 KB.
  • Your queue size will not grow larger than 80 GB.
  • You would like to be able to publish and consume batches of messages.
Queue storage isn't quite as feature-rich, but if you don't need any of those features, it can be a simpler choice. In addition, it's the best solution if your app has any of the following requirements.

Choose Queue storage if:

  • You need an audit trail of all messages that pass through the queue.
  • You expect the queue to exceed 80 GB in size.
  • You want to track progress for processing a message inside of the queue.
A queue is a simple, temporary storage location for messages sent between the components of a distributed application. Use a queue to organize messages and gracefully handle unpredictable surges in demand.
Use Storage queues when you want a simple and easy-to-code queue system. For more advanced needs, use Service Bus queues. If you have multiple destinations for a single message, but need queue-like behavior, use topics.

Wednesday, August 14, 2019

Dynamics 365 Portal Authentication - Using OAuth2.0 Providers

The supported OAuth2.0  providers are:
  • Microsoft Account
  • Twitter
  • Facebook
  • Google
  • LinkedIn
  • Yahoo
They all involve registering the portal application with a third-party service to obtain a client ID and client secret pair. A redirect URL needs to be specified that allows the identity provider to send users back to the portal.

How to configure for Google

  1. Open Google Developers Console
  2. Create an API project or open an existing project
  3. Go toAPIs & auth >APIs, and under Social APIs, selectGoogle+ API, and then selectEnable API
  4. Go toAPIs & auth >Consent screen.
    • Specify anEmail address.
    • Specify a customProduct name.
    • SelectSave.
  5. Go toAPIs & auth >Credentials and create a new client ID.


How to configure for Facebook

  1. Select Add a New App.
  2. Select Website.
  3. Select Skip and Create App ID.
    • Specify a Display Name.
    • Choose a Category.
    • Select Create App ID.
  4. While on the dashboard for the new app, go to Settings >Basic (tab) and add the following details:
  5. Select Save Changes.
  6. Go to Status & Review > Status tab.
  7. Select Yes when prompted to make the app and all its features available to the general public. You must have filled in the valid data in Step 5 above to enable this setting.

How to configure for Microsoft

  1. Open Microsoft account Developer Center
  2. Select Create application and specify an Application name.
  3. Select I accept to accept Terms and Conditions.
  4. Go to Settings >API settings, and then set the redirect URL as http://portal.myexample.com/signin-microsoft

How to configure for Twitter

  1. Select Create New App.
  2. Select Create your Twitter application.

How to configure for LinkedIn

  1. Select Add New Application.
  2. Select Add Application.

How to configure for Yahoo

  1. Select Create an App.
    • Specify an Application Name.
    • Application Type: Web Application.
    • Callback Domain: portal.myexample.com
  2. Select Create App.

Following site settings need to be configured on the portal (replace [provider] with google,facebook,twitter,linkedin,Microsoft,yahoo depending on which one is getting used) :

Site Setting NameDescription
Authentication/Registration/ExternalLoginEnabledEnables or disables external account sign-in and registration. Default: true
Authentication/OpenAuth/[provider]/ClientIdRequired. The client ID value from the provider application. It may also be referred to as an App ID or Consumer Key. The following setting names are allowed for backwards compatibility: Authentication/OpenAuth/Twitter/ConsumerKey
  • Authentication/OpenAuth/Facebook/AppId
  • Authentication/OpenAuth/LinkedIn/ConsumerKey
Authentication/OpenAuth/[provider]/ClientSecretRequired. The client secret value from the provider application. It may also be referred to as an App Secret or Consumer Secret. The following setting names are allowed for backwards compatibility: Authentication/OpenAuth/Twitter/ConsumerSecret
  • Authentication/OpenAuth/Facebook/AppSecret
  • Authentication/OpenAuth/LinkedIn/ConsumerSecret
Authentication/OpenAuth/[provider]/AuthenticationTypeThe OWIN authentication middleware type. Example: yahoo. authenticationoptions.authenticationtype.
Authentication/OpenAuth/[provider]/ScopeA comma separated list of permissions to request. microsoftaccountauthenticationoptions.scope.
Authentication/OpenAuth/[provider]/CaptionThe text that the user can display on a sign in user interface. microsoftaccountauthenticationoptions.caption.
Authentication/OpenAuth/[provider]/BackchannelTimeoutTimeout value in milliseconds for back channel communications. microsoftaccountauthenticationoptions.backchanneltimeout.
Authentication/OpenAuth/[provider]/CallbackPathThe request path within the application's base path where the user-agent will be returned. microsoftaccountauthenticationoptions.callbackpath.
Authentication/OpenAuth/[provider]/SignInAsAuthenticationTypeThe name of another authentication middleware which will be responsible for actually issuing auserClaimsIdentitymicrosoftaccountauthenticationoptions.signinasauthenticationtype.
Authentication/OpenAuth/[provider]/AuthenticationModeThe OWIN authentication middleware mode. security.authenticationoptions.authenticationmode.

Source of this article is https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-oauth2-settings



s

Dynamics 365 Portal Authentication Basics

Dynamics 365 Portal authentication is built on the ASP.NET Identity API which in turn is built on the OWIN framework.
1. Local Authentication
It is the common forms-based authentication which uses the contact records of a Dynamics 365 to store the authentication details( password as hashed text, username etc.) It is going to be deprecated soon. 
2. External Authentication
It uses the ASP.NET Identity API to integrate with the external ID providers. For example. Open ID based providers such as Azure AD and Google, OAuth 2.0 based providers such as Twitter, Facebook, Yahoo, Google and Microsoft, SAML 2.0 based providers.
When using external authentication, the user is required to sign in through the chosen identity provider to prove that they own the external account. During sign-up, a new contact record is created in Dynamics365. 
For portal authentication to work properly, ensure that following solutions exist in the environment"
  1. MicrosoftIdentity
  2. MicrosoftIdentityWorkflows
  3. Microsoft IdentitySystemWorkflows
    Users who have an external account can choose to create a local account by applying a username and password. Users who started with a local account can choose to associate multiple external identities to their account.
     

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/set-authentication-identity has most of the site settings which needs to be configured for either local or external authentication.