Enhanced HTTP request handling by adding support for dynamically including custom headers from the `request.Headers` collection. Implemented a null check to ensure robustness and prevent null reference exceptions when processing headers. This change improves flexibility and customization of HTTP requests.
Improve observability by adding a warning log when `request.BodyQuery` is not null but `request.IsReturnedNoData.BodyQuery` is false.
The log message highlights potential issues, such as skipped `BodyQueryBehavior` execution or missing control steps, and includes `ProfileId` and `ActionId` for better debugging context.
Updated HeaderQueryBehavior to handle null or missing
REQUEST_HEADER gracefully by logging warnings and setting
action.IsReturnedNoData.HeaderQuery to true instead of
throwing exceptions. Enhanced log messages for failed
RawHeader deserialization to improve clarity and added
pipeline continuity by calling await next(cancel).
Refactored log formatting for consistency.
Added `IsReturnedNoData` property as a tuple to track the state
of `BodyQuery` and `HeaderQuery` data returns. Introduced
`PostprocessingQuery` property to support initialization of
post-processing queries. These changes enhance the functionality
of the `RecActionDto` class by enabling better query handling
and processing capabilities.
Previously, the code continued execution when the RawHeader
property of the query result was null. This change introduces
an InvalidOperationException to handle this case, ensuring
that the absence of a valid RawHeader is treated as an error.
The exception message includes ProfileId and ActionId for
better debugging context.
Simplified null-checks in the `Handle` method of the
`BodyQueryBehavior` class using the null-conditional operator.
Enhanced the exception message to include `ProfileId` and
`ActionId` for better debugging context when `result?.RawBody`
is null.
Previously, the `Handle` method in `BodyQueryBehavior<TRecAction>`
did not validate the `BodyQuery` result before setting `action.Body`.
This change introduces a check to ensure that the result and its
`RawBody` are not null. If either is null, an
`InvalidOperationException` is thrown with a clear error message.
This ensures `action.Body` is only set when a valid result is
retrieved, improving robustness and preventing potential null
reference issues.
Added logic to handle non-null `request.Body` in HTTP requests.
Introduced a `StringContent` object to encapsulate the body
content and assigned it to the `Content` property of the
HTTP request. This ensures that the request body is included
when sending data to the specified endpoint.
Updated `HeaderQueryBehavior` to include dependency injection
for `IRecDbContext` and `ILogger`, enabling database interaction
and logging. Replaced the placeholder `NotImplementedException`
in the `Handle` method with functionality to process `HeaderQuery`
SQL results, deserialize JSON headers, and assign them to the
`Headers` property of the action. Added error handling and
logging for deserialization failures. Updated constructor and
method signatures to support new dependencies and asynchronous
behavior. Added necessary `using` directives for new features.
Updated BodyQueryBehavior to process BodyQuery using the
IRecDbContext dependency. Added logic to execute SQL queries
via FromSqlRaw and assign results to the action's Body property.
Removed placeholder NotImplementedException.
Added Microsoft.EntityFrameworkCore.SqlServer package to
ReC.Application.csproj to enable SQL Server database operations.
Refactored `DependencyInjection` to use a generic `TRecDbContext`
for flexibility and added scoped registration for `IRecDbContext`.
Updated `RecDbContext` to implement the new `IRecDbContext`
interface, ensuring adherence to the application-layer contract.
Introduced the `IRecDbContext` interface in the application layer,
defining `DbSet` properties for key entities and a `SaveChangesAsync`
method. Updated `ReC.Infrastructure.csproj` to reference the
application project for interface access.
Added `HeaderQueryResults` and `BodyQueryResults` DbSet
properties to the `RecDbContext` class for interacting
with `HeaderQueryResult` and `BodyQueryResult` entities.
Overrode the `OnModelCreating` method to configure the
`RecAction` entity as keyless using
`modelBuilder.Entity<RecAction>().HasNoKey()`.
Added `HeaderQueryResult` and `BodyQueryResult` classes to represent
query results for headers and bodies, respectively. These classes
map their properties to database columns (`REQUEST_HEADER` and
`REQUEST_BODY`) using the `[Column]` attribute. Both properties
are nullable and immutable.
Updated `RecDbContext` to configure these entities as keyless
using the `HasNoKey()` method in the `OnModelCreating` method,
indicating they are used for read-only queries.
Moved `BodyQueryBehavior` and `HeaderQueryBehavior` from
`ReC.Application.RecActions.Behaviors` to
`ReC.Application.Common.Behaviors` to reflect their broader
applicability. Updated `DependencyInjection.cs` to use the new
namespace. This reorganization improves code structure and
maintainability.
Added `HeaderQueryBehavior<TRecAction>` to handle header query
processing in the MediatR pipeline. Updated the `DependencyInjection`
class to register `HeaderQueryBehavior<>` alongside
`BodyQueryBehavior<>` in the MediatR configuration. The new behavior
currently throws a `NotImplementedException` as its logic is pending
implementation.
Introduced the `BodyQueryBehavior<TRecAction>` class, which implements the `IPipelineBehavior` interface to handle actions of type `RecActionDto`. The behavior is currently unimplemented and throws a `NotImplementedException`.
Updated the `DependencyInjection` class to register `BodyQueryBehavior<>` as an open generic pipeline behavior in MediatR. Added necessary `using` directives in both `DependencyInjection.cs` and `BodyQueryBehavior.cs` to support the new behavior.
Added new properties to `RecActionDto`:
- `Headers` to store HTTP headers as a dictionary.
- `BodyQuery` to represent a query related to the body.
- `Body` to store the body content.
- `PostprocessingQuery` to represent a query for postprocessing.
These changes improve the class's ability to handle HTTP requests and related operations, providing greater flexibility for preprocessing and postprocessing tasks.
Replaced the `reqMsg` variable with `httpReq` to simplify the
creation and usage of `HttpRequestMessage`. The `request.RestType`
is now used directly to create `httpReq`, which is passed to
`http.SendAsync`. This change reduces redundancy and improves
code clarity.
Introduced a new extension method `ToHttpRequestMessage` in
`HttpExtensions` to simplify `HttpRequestMessage` creation
with URI validation. Added `System.Diagnostics.CodeAnalysis`
for `StringSyntaxAttribute` support.
Refactored `InvokeRecActionCommandHandler` to use the new
`ToHttpRequestMessage` method, improving readability and
encapsulation. Renamed `msg` to `reqMsg` for clarity.
Replaced the switch statement in the ToHttpMethod method with
a case-insensitive dictionary for mapping HTTP method strings
to HttpMethod objects. Introduced a private static dictionary
to store predefined HTTP methods, including the addition of
the CONNECT method. Improved performance and maintainability
by leveraging dictionary lookups for faster and cleaner code.
Introduce the ToEndpointUriBuilder() method in the RecActionDto
class to simplify the creation of a UriBuilder object. The method
configures the UriBuilder based on the EndpointUri and ProfileType
properties, setting the port to -1 and the scheme to ProfileType
if provided. This enhances the flexibility and usability of the
RecActionDto class for endpoint URI construction.
Refactored HTTP method handling by introducing a `ToHttpMethod`
extension method in `HttpExtensions.cs` to convert string
representations of HTTP methods to `HttpMethod` objects.
Replaced manual `HttpMethod` instantiation with the new
extension method in `InvokeRecActionCommandHandler` for
improved readability and reusability.
Removed unused `using` directives from `HttpExtensions.cs`
and cleaned up the `namespace` declaration. Added a `using`
directive for `ReC.Application.Common` in
`InvokeRecActionCommand.cs` to support the new extension method.
Updated `InvokeRecActionCommand.cs` to use `using` statements for `HttpClient`, `HttpRequestMessage`, and `HttpResponseMessage` to prevent resource leaks.
Added a new `HttpExtensions.cs` file with a static `HttpExtensions` class as a placeholder for future HTTP-related extension methods. Included necessary `using` directives for potential LINQ, collections, and asynchronous programming.
Refactored the handling of "Rec Actions" by introducing the `InvokeRecActionCommandHandler` class and leveraging the MediatR library for command handling. Simplified the logic in `InvokeBatchRecActionsCommand.cs` by delegating HTTP request handling to the `sender.Send` method, which now uses `InvokeRecActionCommand`.
Updated `InvokeRecActionCommand` to implement the `IRequest` interface, enabling MediatR pipeline compatibility. Added `InvokeRecActionCommandExtensions` for converting `RecActionDto` to `InvokeRecActionCommand`, improving readability.
Centralized HTTP request logic in the new `InvokeRecActionCommandHandler`, which validates `RestType`, sends HTTP requests, and logs warnings for invalid actions. Removed unused `using` directives and added necessary ones for MediatR and logging.
This refactoring improves modularity, testability, and maintainability by separating concerns and streamlining the code structure.
Converted RecActionDto from class to record for immutability
and value-based equality. Added nullable properties
`ActionId` and `ProfileId` to RecActionDto.
Introduced InvokeRecActionCommand.cs, which includes:
- A new InvokeRecActionCommand record inheriting from RecActionDto.
- Constructors for initializing InvokeRecActionCommand.
- An extension method `ToInvokeCommand` for converting
RecActionDto to InvokeRecActionCommand.
Replaced `InvokeRecAction` with `InvokeBatchRecAction` in `ActionController` to transition from single-action to batch-action invocation.
Removed `InvokeRecActionCommand.cs`, which previously handled individual action invocations. Introduced `InvokeBatchRecActionsCommand.cs` to handle batch processing with similar concurrency control logic using a semaphore.
This redesign improves scalability and aligns with updated business requirements while maintaining compatibility with the existing application structure.
Refactored `InvokeRecActionCommand` and `ReadRecActionQuery`
to leverage C# `record` types for immutability and improved
data structure clarity. Introduced `ReadRecActionQueryBase`
as a shared base record to separate common properties and
logic. Updated `InvokeRecActionCommandHandler` to use the
new `ToReadQuery` method for compatibility. These changes
enhance code maintainability, reusability, and separation
of concerns while preserving existing functionality.
Introduced a new `RecAction` configuration section in `appsettings.json` with a `MaxConcurrentInvocations` property. Updated `Program.cs` to use the `Configuration` object to pass the `RecAction` settings to the `AddRecServices` method. Replaced the `MediatRLicense` value in `appsettings.json` with no functional changes.
Organized the `DependencyInjection` class into regions for better code structure: `Required Services`, `Configuration`, `LuckyPennySoftwareLicenseKey`, and `ConfigureRecActions`.
Added `_requiredServices` dictionary to track the configuration status of required services. Updated `LuckyPennySoftwareLicenseKey` to include a null check before marking it as configured.
Moved `_configActions` to the `Configuration` region and added `ApplyConfigurations` to process queued configuration actions.
Enhanced `ConfigureRecActions` to prevent duplicate configurations by throwing an `InvalidOperationException` if already configured.
These changes improve code readability, maintainability, and robustness.
Added `EnsureRequiredServices` to validate required services
in `ConfigurationOptions`, throwing an exception if any are
missing. Introduced `_requiredServices` dictionary to track
configuration status for `ConfigureRecActions` and
`LuckyPennySoftwareLicenseKey`. Updated property and methods
to mark services as configured. Integrated validation into
`AddRecServices` to enforce proper setup.
Updated `DependencyInjection.cs` to include support for
`ConfigurationOptions`, enabling queued configuration actions
and the ability to configure `RecActionOptions` via delegates
or `IConfiguration`. Added `LuckyPennySoftwareLicenseKey`
property to `ConfigurationOptions` and integrated it into
`AddAutoMapper` setup. Introduced `ApplyConfigurations`
method to process queued actions. Updated `using` directives
to include necessary namespaces.
A new `RecActionOptions` class was introduced in the
`ReC.Application.Common.Options` namespace. This class includes
a `MaxConcurrentInvocations` property with a default value of 5,
intended to configure the maximum number of concurrent invocations
allowed. This addition helps centralize and manage concurrency
settings in the application.
Updated `DtoMappingProfile` and `RecActionDto` to use the
`ReC.Application.Common.Dto` namespace instead of
`ReC.Application.Dto`. Adjusted `ReadRecActionQuery` to reflect
this namespace change. No functional changes were introduced.
Enhanced the `InvokeRecActionCommandHandler` class by adding
a `catch` block to handle exceptions during HTTP request and
response processing. Logged exception details, including
`ProfileId` and `ActionId`, using `logger?.LogError` for
better observability. Ensured the `finally` block releasing
the semaphore remains unaffected.
Enhanced the `InvokeRecActionCommandHandler` class by adding
logging functionality using `ILogger`. Updated the constructor
to accept an optional logger parameter. Introduced a check for
`RestType` being `null` and added a warning log to handle such
cases gracefully. This prevents processing invalid actions and
improves system robustness.
Introduced a `SemaphoreSlim` with a concurrency limit of 5 to
control the number of simultaneous HTTP requests. Updated the
HTTP request logic to use `WaitAsync` and `Release` for
managing access to the critical section. Wrapped the HTTP
request handling in a `try-finally` block to ensure proper
semaphore release, even in case of exceptions. This change
improves resource management and prevents overwhelming the
HTTP client or the target server.
Replaced sequential `foreach` loop with LINQ's `Select` to create a collection of tasks for sending HTTP requests asynchronously. Added `Task.WhenAll` to execute all requests concurrently, improving performance. Removed the old `foreach` implementation in favor of a functional programming approach.
Added a call to `services.AddHttpClient();` in the `DependencyInjection` class within `DependencyInjection.cs`. This change registers the `HttpClient` service in the dependency injection container, allowing the application to use managed `HttpClient` instances.
Updated `ReC.Application.csproj` to include `Microsoft.Extensions.Http` for improved HTTP client management. Refactored `InvokeRecActionCommandHandler` to use `IHttpClientFactory` for creating `HttpClient` instances, enhancing resource efficiency. Simplified HTTP method handling by replacing the switch statement with a dynamic `HttpMethod` and `HttpRequestMessage` approach. Removed redundant `using` directives and renamed `header` to `headers` for clarity. Removed `BadRequestException` for unsupported REST types, streamlining error handling.
In the `InvokeRecActionCommandHandler` class, added code to read the response content as a string and store it in a `body` variable. Also, converted response headers into a dictionary and stored them in a `header` variable. These changes facilitate further processing of the response content and headers.
Extended the switch expression in `InvokeRecActionCommand.cs` to handle additional HTTP methods: "PATCH", "HEAD", "OPTIONS", and "TRACE".
Implemented the appropriate asynchronous HTTP requests using `HttpClient`.
"PATCH" uses `http.PatchAsync`, while "HEAD", "OPTIONS", and "TRACE" use `http.SendAsync` with a new `HttpRequestMessage`.
A `BadRequestException` is thrown for unsupported methods.
Replaced the `switch` statement with a `switch` expression to handle HTTP methods (`GET`, `POST`, `PUT`, `DELETE`). This refactoring reduces boilerplate code and improves readability by directly assigning the HTTP request result to the `response` variable, eliminating the need for multiple `using` and `break` statements.
Implemented the handling of DELETE HTTP requests in the
InvokeRecActionCommandHandler class. Previously, the DELETE
case was unhandled, and now it uses http.DeleteAsync to
send a DELETE request to the specified action.EndpointUri,
supporting cancellation with the cancel token.
Implemented HTTP PUT request handling in the
InvokeRecActionCommandHandler class. Previously, the PUT case
only had a placeholder comment. Now, it uses
http.PutAsync to send a PUT request to the specified
action.EndpointUri, aligning it with the existing POST
request handling.
Previously, the handling of HTTP POST requests in the
InvokeRecActionCommandHandler class was not implemented.
This commit adds the necessary code to handle POST requests
by using the http.PostAsync method. The POST request is sent
to the specified action.EndpointUri with null content and a
cancellation token. This change ensures that POST operations
are now properly executed within the command handler.
Updated the HTTP request handling logic within the action loop to dynamically construct requests based on the `RestType` and `EndpointUri` of each action. Expanded the switch statement to handle GET, POST, PUT, and DELETE methods, allowing for specific logic to be implemented for each. Removed the hardcoded URL and response content retrieval, indicating potential refactoring of response handling. The default case continues to throw a `BadRequestException` for unsupported REST types.
Convert RestType to uppercase in the switch statement to
ensure case-insensitive matching of REST types. This change
handles variations like "get", "Get", and "GET" consistently.
Additionally, use the null-conditional operator to prevent
NullReferenceException when RestType is null.
Refactor `using` directives in `InvokeRecActionCommand.cs` to include `DigitalData.Core.Exceptions` and `System.Net.Http`.
Implement logic in `InvokeRecActionCommandHandler` to handle different REST actions using `HttpClient`. Introduce a `switch` statement to process "GET", "POST", "PUT", and "DELETE" actions, with a `BadRequestException` for unsupported types. Read HTTP response content asynchronously.
