[DEMO] Use Mod Header extension to impersonate a user in Dynamics 365 CRM
[DEMO] Use Mod Header extension to impersonate a user in Dynamics 365 CRM
[DEMO] Add new/custom item/choice into Dropdown list in Canvas App
[DEMO] Add new/custom item/choice into Dropdown list in Canvas App
[TIPS] How to check if filter result is null or vacant
[TIPS] How to check if filter result is null or vacant
[TIPS] Add new line to the string / String concatenate with new line in Power Apps Canvas App
Add new line to the string / String concatenate with new line in Power Apps Canvas App
How Service Protection API Limits are enforced
How Service Protection API Limits are enforced
Service protection API limits are enforced based on three facets:
- The number of requests sent by a user.
- The combined execution time required to process requests sent by a user.
- The number of concurrent requests sent by a user.
If the only limit was on the number of requests sent by a user, it would be possible to bypass it. The other facets were added to counter these attempts. For example:
- You could send fewer requests by bundling them in batch operations.
- The combined execution time limit will counter this.
- Rather than sending requests individually in succession, you could send a large number of concurrent requests before service protection API limits are enforced.
- The concurrent request limit will counter this.
Each web server available to your environment will enforce these limits independently. Most environments will have more than one web server. Trial environments are allocated only a single web server. The actual number of web servers that are available to your environment depends on multiple factors that are part of the managed service we provide. One of the factors is how many user licenses you have purchased.
The following table describes the default service protection API limits enforced per web server:
[TIPS] How to Install Power Query Connector in VS2019 SSIS
[TIPS] How to Install Power Query Connector in VS2019 SSIS
[Demo] Control your TESLA through Siri and Power Automate
[Demo] Control your TESLA through Siri and Power Automate
Imagine a scenario: in a freezing cold winter, you are heading to the parking lot for your Tesla car. You are holding a big box and have no hand to take out the phone then choose the commands from the menus to turn on the AC remotely, or open the rear trunk. So you just talk to your Apple watch and tell Siri to command the car easily and promptly. Is it an interesting experience you wanna try? If so, you may follow the below steps to finish your personal control application.
As operator in Power Fx
As operator in Power Fx
Use the As operator to name a record in a gallery or record scope function, overriding the default ThisItem or ThisRecord. Naming the record can make your formulas easier to understand and may be required in nested situations to access records in other scopes.
A few controls and functions apply formulas to individual records of a table. To refer to the individual record in a formula, use one of the following:
SQL: Data type for image
SQL: Data type for image
The ntext, text, and image data types will be removed in a future version of SQL Server. Avoid using these data types in new development work, and plan to modify applications that currently use them. Use nvarchar(max), varchar(max), and varbinary(max) instead.
SQL: VARCHAR vs NVARCHAR
SQL: VARCHAR vs NVARCHAR
varchar is used for non-Unicode characters only on the other hand nvarchar is used for both unicode and non-unicode characters. Some other difference between them is given below.
SQL: VARCHAR(N) vs VARCHAR(MAX)
SQL: VARCHAR(N) vs VARCHAR(MAX)
When choosing data type, we should consider the database design, performance, compression, and indexes in mind.
We can define a specific range for the varchar (n) data type, and it is the recommended way to do so.
Varchar (n) can store up to 8000 bytes of data using varchar (8000) data type.
Varchar (max) can store data up to 2 GB.
Introduction - Cloud architecture for Business Central
Introduction - Cloud architecture for Business Central
Business Central is a full cloud solution, and its architecture is illustrated in the following diagram.
REST vs OData
REST vs OData
Understanding the Concept of REST APIs
REST (REpresentational State Transfer) refers to a Software Architectural Style that defines the standards for exchanging information between two different systems via the HTTP Protocol. It is the most popular architecture for exchanging data on the World Wide Web.
REST defines 6 different principles for Web Services:
- Uniform Interface: All components in a REST system must adhere to the same interface and rules so as to communicate with each other.
- Client-Server: REST separates Servers from Clients. The Servers store information, while the Clients retrieve information from the Servers.
- Stateless: All requests made via REST are stateless. They have all the necessary information needed by the Server to execute the request.
- Cacheable: In REST, both Clients and Servers can cache resources, which is good for reducing traffic and improving performance.
- Layered System: REST supports a Layered System Architecture. The Client may communicate with one Server, while the other Servers perform tasks such as Data Storage and Authentication.
- Code on Demand: REST requisitions may return executable code or logic when necessary (optional).
Any API (Application Programming Interface) that follows the above principles is referred to as a REST API. In most cases, REST APIs use XML or JSON, but the REST Architecture doesn’t require anything specific as far as this is concerned. REST does not require any particular format, but it accepts any format that can be used in Content Negotiation.
Understanding the Concept of OData
OData (Open Data Protocol) is a set of best practices for developing and using RESTful APIs. It helps you to focus on your Business Logic while creating RESTful APIs without the need to worry about various ways to define request and response Headers, HTTP Methods, Status Codes, Media Types, URL Conventions, Payload Formats, and more.
OData carries the following specifications:
- It must follow REST principles unless there is a clear reason why it should not.
- The OData services MUST have support for Atom encoding.
- OData services SHOULD have support for JSON encoding.
REST is the most essential component technology of OData. OData 3.0 standards require OData users to follow REST principles. OData rests on HTML technology, which resolves the problem of being REST-based in a way. It supports two Protocols for Data Transfer, the XML-based Atom format and JSON.
OData also has guidance for performing actions like defining reusable procedures, tracking changes, and sending many REST requests.
It provides two models for Data Management which include:
- Entity Data Model (EDM): This is an abstract Data Model that OData users MUST use to describe the exposed data.
- Service Model: It is made up of Static Resources and a set of Dynamic Resources. The work of the Static Resources is to provide a way of asking the Service about its Data Model, while the Dynamic Resources provide methods to manage the Data Model.
In the next section, we will be discussing OData vs REST APIs to know how the two compare in different core areas.
OData vs REST APIs: What’s the Difference?
Let’s now discuss how OData and REST APIs compare to each other:
OData vs REST APIs: Function
REST Function
REST is an architecture that defines how to send messages between a Client and a Server via HTTP. It is a model that states that you can use HTTP and its verbs to perform CRUD Operations (Create, Read, Update, Delete) on the resources exposed by your Services. Thus, REST is more concerned about the architecture.
OData Function
OData is a standard from Microsoft that relies on the REST Architecture to send specific types of messages over HTTP. It defines metadata in CSDL (Common Schema Definition Language) format to describe the Entity types supported by your Service and their Properties, Data types, and more. Thus, OData is more concerned about the content.
OData vs REST APIs: Principles
REST Principles
REST defines 6 principles, as has been listed above, to ensure the creation of efficient Web Services and REST APIs must follow these principles. These principles ensure the success of REST Projects.
OData Principles
OData is built on top of the REST Framework, thus, it depends on REST principles. Note that even though OData recommends its users to follow REST principles every time, the requirement can be relaxed in the case of a good reason. A very basic, Compliant Service should be easy to build, with additional work necessary only to support additional capabilities.
OData vs REST APIs: Best Use Case
REST API Best Use Case
REST is used when there is a need to interact with a Data Source, for example, to retrieve data for all Products. It is easier and faster to parse data using REST APIs. It uses URI to expose the Business Logic.
The following operations are available on HTTP:
OData Best Use Case
OData is best used to expose Services and APIs to Systems and Applications. It has facilities for extension to achieve the custom needs of the REST APIs.
OData vs REST APIs: Data Transfer Format
REST Data Transfer Format
Data transfer format is an important factor to consider when comparing OData vs REST. REST supports the transfer of data in any format. Although most REST APIs use XML and JSON formats, REST is not specific in regard to this.
OData Data Transfer Format
OData specifies that the data should be transferred in either JSON, XML, or Atom format.
Those were the major differences between OData vs REST.
Conclusion
This blog discussed fine differences across OData vs REST APIs. We also discussed concepts behind OData and REST APIs, their specifications and principles.
For Businesses, extracting complex data from a diverse set of Data Sources such as REST APIs can be a challenging task. This is where Hevo saves the day by providing an efficient, reliable and fast ETL Service.
[DEMO] Synchronize Data from Business Central to Dynamics CE (Dataverse) through OData (Web API)
Synchronize Data from Business Central to Dynamics CE (Dataverse) through OData (Web API)
Business Central Web Services: Page vs Codeunit vs Query Differences
Business Central Web Services
Business Central supports three types of web services: API, SOAP, and OData.
[Tutorial] Power BI Data Refresh
Power BI Data Refresh
In this tutorial, we will see what is data refresh in Power BI and how to schedule refresh in Power BI. And also we will discuss
[TIPS] Hide date format "12/31/2001" when date filed is unselected or blank in Canvas App
Issue:
In Power Apps (Canvas App), when use SharePoint as the data source, the date field always shows "12/31/2001" even this field is blank or not selected.
[TIPS] Power Apps SharePoint form setting date/time field to blank
Power Apps SharePoint form setting date/time field to blank
ISSUE: Can't clear a datetime field in SharePoint from PowerApps.
[TIPS] Add "Other" to PowerApps Canvas App Dropdown Field
Dropdown menus allow app users to select a pre-defined value from a list of options. But sometimes you want the user to fill-in their own value using a text input their selection cannot be found in the list. In this article I will show you how to create a dropdown with an other option in Power Apps.
Subscribe to:
Posts (Atom)