@ -0,0 +1,55 @@ |
|||
Summer is here, and so is one of the best times to start building with ABP. |
|||
|
|||
From **July 6 to July 20**, we're offering exclusive summer savings on **ABP licenses and renewals**. Save **20% on new licenses** or **10% on license renewals**, and receive **up to $300 in AI credits** to power the **ABP AI Agent** in **ABP Studio**. |
|||
|
|||
Whether you're starting a new project or upgrading your development workflow, this campaign helps you save on your license while accelerating development with AI. |
|||
|
|||
### **What's Included?** |
|||
|
|||
**During the campaign period, you'll receive:** |
|||
|
|||
* **20% off new ABP licenses** |
|||
* **10% off license renewals** |
|||
* **Up to $300 in AI credits** for the **ABP AI Agent** |
|||
|
|||
The AI credits can be used with the **ABP AI Agent** in **ABP Studio**, allowing you to automate repetitive development tasks and build applications faster. |
|||
|
|||
### **Build Faster with the ABP AI Agent** |
|||
|
|||
The ABP AI Agent is designed specifically for ABP developers. Rather than acting as a generic coding assistant, it understands your ABP solution and helps automate common development workflows. |
|||
|
|||
With the included AI credits, you can: |
|||
|
|||
* Generate application features with AI assistance |
|||
* Create entities, services, and UI components faster |
|||
* Run automated development workflows |
|||
* Generate database migrations and update projects |
|||
* Inspect exceptions and troubleshoot issues |
|||
* Execute development tasks directly from ABP Studio |
|||
|
|||
The result is less time spent on repetitive work and more time focused on building your application's business value. |
|||
|
|||
### **Why Choose ABP?** |
|||
|
|||
ABP is a complete application development platform for building modern, maintainable, and scalable .NET applications. |
|||
|
|||
With ABP, you can: |
|||
|
|||
* Build enterprise-grade ASP.NET Core applications faster |
|||
* Follow Domain-Driven Design (DDD) and clean architecture principles |
|||
* Develop modular, reusable, and maintainable application modules |
|||
* Leverage built-in capabilities such as multi-tenancy, authentication, authorization, localization, auditing, and more |
|||
* Scale from modular monoliths to microservice architectures |
|||
* Boost developer productivity with ABP Studio and the ABP AI Agent |
|||
|
|||
Instead of spending weeks building common infrastructure, your team can focus on delivering business value and shipping features faster. |
|||
|
|||
## **Don't Miss This Limited-Time Offer** |
|||
|
|||
This campaign is available **only between July 6 and July 20**. |
|||
|
|||
Whether you're purchasing your first ABP license or renewing your existing one, now is the perfect time to save. Get **20% off new licenses** or **10% off renewals**, plus receive **up to $300 in AI credits** to accelerate development with the **ABP AI Agent**. |
|||
|
|||
**Claim your summer discount before July 20 and start building faster with ABP.** |
|||
|
|||
**Get your discount now:** [https://abp.io/pricing](https://abp.io/pricing) |
|||
@ -0,0 +1,180 @@ |
|||
# ABP Platform 10.6 RC Has Been Released |
|||
|
|||
We are happy to release [ABP](https://abp.io) version **10.6 RC** (Release Candidate). This blog post introduces the new features and important changes in this new version. |
|||
|
|||
Try this version and provide feedback for a more stable version of ABP v10.6! Thanks to you in advance. |
|||
|
|||
## Get Started with the 10.6 RC |
|||
|
|||
You can check the [Get Started page](https://abp.io/get-started) to see how to get started with ABP. You can either download [ABP Studio](https://abp.io/get-started#abp-studio-tab) (**recommended**, if you prefer a user-friendly GUI application - desktop application) or use the [ABP CLI](https://abp.io/docs/latest/cli). |
|||
|
|||
By default, ABP Studio uses stable versions to create solutions. Therefore, if you want to create a solution with a preview version, first you need to create a solution and then switch your solution to the preview version from the ABP Studio UI: |
|||
|
|||
 |
|||
|
|||
## Migration Guide |
|||
|
|||
You can check the migration guide if you are upgrading from v10.5 or earlier: [ABP Version 10.6 Migration Guide](https://abp.io/docs/10.6/release-info/migration-guides/abp-10-6). |
|||
|
|||
## What's New with ABP v10.6? |
|||
|
|||
In this section, I will introduce some major features released in this version. |
|||
Here is a brief list of titles explained in the next sections: |
|||
|
|||
- Background Jobs: Dedicated Workers, Parallel Execution, and Successful Job Retention |
|||
- API Definition and Proxy Improvements for Content Types and Multipart Uploads |
|||
- Angular UI: Upgrade to Angular 22 |
|||
- Antiforgery and OpenIddict Security Improvements |
|||
- OpenIddict: Generate Access Token from the UI |
|||
- Dependency Updates |
|||
|
|||
### Background Jobs: Dedicated Workers, Parallel Execution, and Successful Job Retention |
|||
|
|||
ABP v10.6 adds three opt-in enhancements to the default background job worker. All of them are disabled by default, so existing applications keep the current behavior unless you enable them explicitly. |
|||
|
|||
**Storing successful jobs** |
|||
|
|||
By default, a job is deleted as soon as it runs successfully. You can now set `StoreSuccessfulJobs = true` to keep completed jobs in the store. A new `CompletionTime` column marks completed jobs, and a cleanup worker prunes them after `SuccessfulJobRetentionTime` (default: 7 days). |
|||
|
|||
**Dedicated workers per job type** |
|||
|
|||
`AddDedicatedWorker(...)` registers a worker that processes only the configured job argument types, each with its own distributed lock. The default worker continues handling all remaining job types. |
|||
|
|||
**Parallel job execution** |
|||
|
|||
Set `MaxParallelJobExecutionCount` greater than 1 to execute multiple jobs in the same poll cycle. In this mode, each job is claimed with its own distributed lock so different application instances can process different jobs concurrently without running the same job twice. |
|||
|
|||
Example configuration: |
|||
|
|||
```csharp |
|||
Configure<AbpBackgroundJobWorkerOptions>(options => |
|||
{ |
|||
options.StoreSuccessfulJobs = true; |
|||
options.SuccessfulJobRetentionTime = TimeSpan.FromDays(30); |
|||
|
|||
options.AddDedicatedWorker<EmailJobArgs, SmsJobArgs>("NotificationWorkerLock"); |
|||
options.AddDedicatedWorker<ReportJobArgs>("ReportWorkerLock"); |
|||
|
|||
options.MaxParallelJobExecutionCount = 4; |
|||
}); |
|||
``` |
|||
|
|||
These options are useful when you need better isolation between job types, higher throughput in clustered deployments, or an audit trail of successfully completed jobs. |
|||
|
|||
> See the [Background Jobs](https://abp.io/docs/10.6/framework/infrastructure/background-jobs) documentation and [#25742](https://github.com/abpframework/abp/pull/25742) for details. |
|||
|
|||
### API Definition and Proxy Improvements for Content Types and Multipart Uploads |
|||
|
|||
ABP v10.6 improves API definition generation and client proxies for file upload scenarios and non-JSON response types. |
|||
|
|||
The API definition now exposes response `ContentTypes` and an `IsRemoteStream` flag. C#, jQuery, and Angular proxies can use the declared media type instead of collapsing everything to `application/json` and `text/plain`. |
|||
|
|||
For upload DTOs containing `IRemoteStreamContent`, generated Angular and jQuery proxies now forward `FormData` as multipart requests instead of silently dropping the file payload or trying to serialize the stream as JSON. |
|||
|
|||
Server-side setup still follows the existing ABP pattern: |
|||
|
|||
```csharp |
|||
Configure<AbpAspNetCoreMvcOptions>(options => |
|||
{ |
|||
options.ConventionalControllers.FormBodyBindingIgnoredTypes.Add(typeof(UploadFileDto)); |
|||
}); |
|||
``` |
|||
|
|||
Angular client example after proxy regeneration: |
|||
|
|||
```typescript |
|||
const fd = new FormData(); |
|||
fd.append('Name', 'logo'); |
|||
fd.append('File', fileInput.files[0], 'logo.png'); |
|||
this.fileService.uploadFile(fd).subscribe(result => ...); |
|||
``` |
|||
|
|||
This closes long-standing gaps in generated proxies for stream-based uploads and improves support for text, blob, and custom response types. |
|||
|
|||
> See [#25639](https://github.com/abpframework/abp/pull/25639) for details. |
|||
|
|||
### Angular UI: Upgrade to Angular 22 |
|||
|
|||
ABP v10.6 upgrades the Angular UI stack to **Angular 22.0.x**. |
|||
|
|||
This release also improves the locale loading mechanism with a fallback path, so culture resources load more reliably when optional locale files are missing or partially available. |
|||
|
|||
If you maintain a custom Angular UI on top of ABP, plan for the Angular 22 upgrade together with your ABP package update and regenerate proxies after upgrading. |
|||
|
|||
> See [#25690](https://github.com/abpframework/abp/pull/25690) and [#25734](https://github.com/abpframework/abp/pull/25734) for details. |
|||
|
|||
### Antiforgery and OpenIddict Security Improvements |
|||
|
|||
ABP v10.6 includes several security-focused fixes for mixed authentication scenarios. |
|||
|
|||
**Antiforgery claim issuer normalization** |
|||
|
|||
When an application serves a token-authenticated SPA and cookie-authenticated MVC pages on the same origin, antiforgery validation could fail because the user id claim issuer differed between JWT and cookie authentication schemes. ABP now normalizes the user id claim issuer while generating and validating antiforgery tokens. |
|||
|
|||
This behavior is enabled by default through `AbpAntiForgeryOptions.NormalizeUserIdClaimIssuer`. Razor Pages antiforgery validation was also aligned with the same normalization logic, which fixes failures in modules such as Setting Management. |
|||
|
|||
**Prevent OpenIddict `client_id` from leaking into the interactive auth cookie** |
|||
|
|||
ABP fixed a case where an OpenIddict authorization request could stamp the requested `client_id` into the interactive authentication cookie during security-stamp refresh. That could corrupt audit logs and make later cookie-authenticated requests appear to belong to the OAuth client. |
|||
|
|||
The fix strips `client_id` when the interactive cookie is refreshed. Tokens are unaffected, and cookies that were already corrupted self-heal on the next refresh. |
|||
|
|||
**Forward the current access token for authenticated client requests** |
|||
|
|||
`HttpContextAbpAccessTokenProvider` now forwards the incoming access token whenever the request is authenticated, including `client_credentials` requests. This prevents unnecessary fallback to configured identity clients in machine-to-machine scenarios. |
|||
|
|||
> See [#25655](https://github.com/abpframework/abp/pull/25655), [#25669](https://github.com/abpframework/abp/pull/25669), [#25711](https://github.com/abpframework/abp/pull/25711), and [#25740](https://github.com/abpframework/abp/pull/25740) for details. |
|||
|
|||
### OpenIddict: Generate Access Token from the UI |
|||
|
|||
ABP Commercial v10.6 RC adds a **Generate Access Token** action to OpenIddict application management pages across MVC, Blazor, MudBlazor, and Angular UIs. |
|||
|
|||
Administrators can request a token for an OpenIddict application directly from the UI. The backend forwards a `client_credentials` request to `/connect/token` and returns the generated access token to the caller. |
|||
|
|||
This is especially useful for testing integrations, validating scopes, and troubleshooting machine-to-machine authentication without leaving the admin UI. |
|||
|
|||
### Dependency Updates |
|||
|
|||
ABP v10.6 RC includes several dependency and package updates: |
|||
|
|||
- Angular packages upgraded to **22.0.x** |
|||
- `Microsoft.*` and `System.*` packages upgraded to **10.0.9** |
|||
- `Microsoft.Data.SqlClient` upgraded to **7.0.2** |
|||
- `Swashbuckle.AspNetCore` upgraded to **10.2.3** |
|||
|
|||
> Check the [Package Version Changes](https://abp.io/docs/10.6/package-version-changes) document for all updates. |
|||
|
|||
### Other Improvements and Enhancements |
|||
|
|||
- **Permission management**: Skip dynamic permission initialization during migration runs to avoid noisy logs when the database is unavailable ([#25743](https://github.com/abpframework/abp/pull/25743)). |
|||
- **Security / principal access**: `ThreadCurrentPrincipalAccessor` now returns an anonymous principal instead of `null` in non-web contexts ([#25752](https://github.com/abpframework/abp/pull/25752)). |
|||
- **Angular proxy generation**: Array parameters are now generated as `readonly` in Angular proxies ([#25687](https://github.com/abpframework/abp/pull/25687)). |
|||
- **Date/time normalization**: Removed misleading warnings when normalizing `Unspecified` `DateTime` values near range boundaries ([#25703](https://github.com/abpframework/abp/pull/25703)). |
|||
- **AI Management**: Indexing is more resilient under memory pressure in the commercial module. |
|||
|
|||
## Community News |
|||
|
|||
### New ABP Community Articles |
|||
|
|||
As always, exciting articles have been contributed by the ABP community. I will highlight some of them here: |
|||
|
|||
- [ABP 10.5.0 Expands Blazor UI Options with MudBlazor Support](https://abp.io/community/articles/abp-10.5.0-expands-blazor-ui-options-with-mudblazor-support-03rzmlpm) by [Liming Ma](https://abp.io/community/members/maliming) |
|||
- [Angular 22 State Management: Signals, SignalStore, or NgRx?](https://abp.io/community/articles/angular-22-state-management-signals-signalstore-or-ngrx-yq8zg0nw) by [Sumeyye Kurtulus](https://abp.io/community/members/sumeyye.kurtulus) |
|||
- [Working with Dapr Workflows in the ABP Framework](https://abp.io/community/articles/working-with-dapr-workflows-in-the-abp-framework-6476or18) by [Engincan Veske](https://abp.io/community/members/EngincanV) |
|||
- [My Speaker's View of CONVEX Summit 2026](https://abp.io/community/articles/my-speakers-view-of-convex-summit-2026-ai-net-conference-3uk6ln1l) by [Alper Ebiçoğlu](https://abp.io/community/members/alper) |
|||
|
|||
Thanks to the ABP Community for all the content they have published. You can also [post your ABP related (text or video) content](https://abp.io/community/posts/create) to the ABP Community. |
|||
|
|||
### ABP Summer Campaign: Get Up To 20% Off + $300 in AI Credits |
|||
|
|||
 |
|||
|
|||
Summer is a great time to start building with ABP. From **July 6 to July 20**, we're offering exclusive summer savings on **ABP licenses and renewals**: **20% off new licenses**, **10% off renewals**, and **up to $300 in AI credits** for the **ABP AI Agent** in **ABP Studio**. Whether you're starting a new project or upgrading your development workflow, this limited-time offer helps you save on your license while accelerating development with AI. |
|||
|
|||
> You can read the announcement here: [ABP Summer Campaign: Get Up To 20% Off + $300 in AI Credits](https://abp.io/community/announcements/abp-summer-campaign-get-up-to-20-off-300-in-ai-credits-r5lqtpg9). |
|||
|
|||
## Conclusion |
|||
|
|||
This version comes with some new features and a lot of enhancements to the existing features. You can see the [Road Map](https://abp.io/docs/10.6/release-info/road-map) documentation to learn about the release schedule and planned features for the next releases. Please try ABP v10.6 RC and provide feedback to help us release a more stable version. |
|||
|
|||
Thanks for being a part of this community! |
|||
|
After Width: | Height: | Size: 470 KiB |
|
After Width: | Height: | Size: 34 KiB |
|
After Width: | Height: | Size: 94 KiB |
|
After Width: | Height: | Size: 379 KiB |
|
After Width: | Height: | Size: 244 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 31 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 21 KiB |
|
After Width: | Height: | Size: 23 KiB |
|
After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 9.1 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 45 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 181 KiB |
@ -0,0 +1,394 @@ |
|||
# Building a Vendor Onboarding Workflow with ABP Low-Code |
|||
|
|||
Vendor onboarding usually starts with a few familiar steps. |
|||
|
|||
A company sends its details, someone checks the documents, another person reviews the score, and the team either approves the vendor or asks for more information. After a while, the process turns into a mix of spreadsheets, uploaded files, status notes, and "who is waiting on this one?" messages. |
|||
|
|||
In this article, we'll build that workflow with the [Low-Code System](https://abp.io/docs/latest/low-code/index). We'll model the data in the [Low-Code Designer](https://abp.io/docs/latest/low-code/designer), let the [React runtime](https://abp.io/docs/latest/low-code/react-runtime) render the page, and then add one [custom endpoint](https://abp.io/docs/latest/low-code/custom-endpoints) for a summary that does not belong to normal CRUD. |
|||
|
|||
The example is an internal operations page where a team receives vendor applications, reviews compliance documents, tracks deadlines, and follows rejected or priority vendors from one place. |
|||
|
|||
That is a good place to try ABP Low-Code, because the first version of the workflow is mostly data, screens, validation rules, and a few process-specific actions. You do not need to hand-write a React page only to list vendor applications, upload a compliance document, or show a rejection reason when the status is rejected. |
|||
|
|||
We will start from an already running ABP React + EF Core application with Low-Code enabled, so the article can stay focused on the Admin Console, the Designer, and the runtime flow. |
|||
|
|||
## What We Are Building |
|||
|
|||
The workflow has one main record: `VendorApplication`. |
|||
|
|||
A reviewer should be able to: |
|||
|
|||
- Create a vendor application with company and contact details. |
|||
- Track whether the vendor is `Submitted`, `InReview`, `Approved`, or `Rejected`. |
|||
- Set the requested date and approval deadline. |
|||
- Mark priority vendors. |
|||
- Assign a category such as `Software`, `Services`, or `Hardware`. |
|||
- Upload a logo and a compliance document. |
|||
- Fill in a rejection reason only when the application is rejected. |
|||
- Filter the generated grid by status, requested date, priority, and category. |
|||
- Call a summary endpoint that returns counts for dashboard-like use. |
|||
|
|||
We'll also touch two extra pieces around that main record. `VendorReviewTemplate` comes from C# so you can see how code-defined metadata appears in the Designer. Later, a `VendorEscalation` model is added while the Designer is switched to `Runtime JSON`. You could build the whole workflow with one entry point, but using these three entry points makes the hybrid model visible without turning the article into three separate implementations. |
|||
|
|||
## A Quick Note on How Low-Code Fits Together |
|||
|
|||
The Low-Code Designer is where you describe the model and the UI metadata. In this article we use four areas: |
|||
|
|||
- `Data` for enums and entities. |
|||
- `Pages` for the generated grid route. |
|||
- `Forms` for the create/edit form layout. |
|||
- `Actions` for the custom HTTP endpoint. |
|||
|
|||
The Designer stores metadata. The React runtime reads that metadata and renders the page at runtime. That is the important mental model: when we add a field to the entity, the field can become a grid column, a filter, a validation rule, or a form input depending on how we configure the metadata around it. |
|||
|
|||
There is also one database detail to keep in mind. Metadata that comes from C# code or from `Dev JSON` is source-controlled application metadata. When it introduces or changes a persisted entity, run the normal EF Core migration and database update flow before using the generated runtime page. In the validated demo for this article I used SQLite, so the migration updated the local SQLite database. `Runtime JSON` is different: it is authored at runtime, so I do not run a C# migration in that section. |
|||
|
|||
## Add a Code-Defined Review Template |
|||
|
|||
Let's start with one model that does not come from the Designer. |
|||
|
|||
In this workflow, vendor reviewers can use review templates. The template itself is not the center of the workflow, so I kept it focused on the review rules: |
|||
|
|||
```csharp |
|||
[DynamicEnum] |
|||
public enum VendorReviewTemplateType |
|||
{ |
|||
Standard = 0, |
|||
Security = 1, |
|||
Finance = 2 |
|||
} |
|||
|
|||
[DynamicEntity(DefaultDisplayPropertyName = nameof(Name))] |
|||
[DynamicEntityUI(DisplayName = "Vendor Review Templates")] |
|||
public class VendorReviewTemplate : DynamicEntityBase |
|||
{ |
|||
[Required] |
|||
[StringLength(128)] |
|||
[DynamicPropertyUnique] |
|||
public string Name { get; set; } |
|||
|
|||
public VendorReviewTemplateType TemplateType { get; set; } |
|||
public int MinimumComplianceScore { get; set; } |
|||
public bool RequiresDocumentReview { get; set; } |
|||
public string? Notes { get; set; } |
|||
} |
|||
``` |
|||
|
|||
Then include the entity in your EF Core DbContext. This is the part that makes the migration create a real backing table for the code-defined model: |
|||
|
|||
```csharp |
|||
public DbSet<VendorReviewTemplate> VendorReviewTemplates { get; set; } |
|||
|
|||
builder.Entity<VendorReviewTemplate>(b => |
|||
{ |
|||
b.ToTable( |
|||
VendorOnboardingLowCodeConsts.DbTablePrefix + "VendorReviewTemplates", |
|||
VendorOnboardingLowCodeConsts.DbSchema |
|||
); |
|||
b.ConfigureByConvention(); |
|||
b.Property(x => x.Name).IsRequired().HasMaxLength(128); |
|||
b.Property(x => x.Notes).HasMaxLength(512); |
|||
b.HasIndex(x => x.Name).IsUnique(); |
|||
}); |
|||
``` |
|||
|
|||
Because this model is defined in C#, treat it like the rest of your application schema changes: add the entity, add the DbSet/mapping, create/apply the EF Core migration, and then start the application. |
|||
|
|||
After the app starts, open **Admin Console > Low-Code Designer > Data**. The model is visible there, but it is read-only because it was defined in code. |
|||
|
|||
 |
|||
|
|||
Open the **Properties** tab and you can see the fields that came from the C# class. They are available to the Low-Code System, but the Designer marks them as code-owned. |
|||
|
|||
 |
|||
|
|||
That is useful in real projects. Some metadata can be shipped with the application, while the rest of the workflow can still be designed through the Admin Console. |
|||
|
|||
## Create the Vendor Enums |
|||
|
|||
Now move to the part we actually build in the Designer. |
|||
|
|||
The animation below shows the Designer path in one pass. The next sections slow it down and explain the enum, entity, page, and form steps. |
|||
|
|||
 |
|||
|
|||
Open `Data > Enums` and create the status enum: |
|||
|
|||
```text |
|||
VendorApplicationStatus |
|||
Submitted |
|||
InReview |
|||
Approved |
|||
Rejected |
|||
``` |
|||
|
|||
Before saving, the enum modal should contain the name and the four values: |
|||
|
|||
 |
|||
|
|||
Then create the category enum: |
|||
|
|||
```text |
|||
VendorCategory |
|||
Software |
|||
Services |
|||
Hardware |
|||
``` |
|||
|
|||
The order of the status values matters for the custom endpoint later, because the script checks the enum values by their numeric indexes. In this example `Submitted` is `0`, `Approved` is `2`, and `Rejected` is `3`. |
|||
|
|||
After saving, the enum detail page shows the numeric values that the runtime and scripts will use: |
|||
|
|||
 |
|||
|
|||
## Create the VendorApplication Entity |
|||
|
|||
Go to `Data > Entities` and create `VendorApplication`. |
|||
|
|||
This is the model that drives the rest of the article. Add these fields: |
|||
|
|||
| Field | Type | Configuration | |
|||
| --- | --- | --- | |
|||
| `CompanyName` | `String` | Required and unique | |
|||
| `ContactEmail` | `String` | Required, email validation | |
|||
| `Status` | `Enum` | `VendorApplicationStatus` | |
|||
| `RequestedOn` | `Date` | Application date | |
|||
| `ApprovalDeadline` | `Date` | Review deadline | |
|||
| `IsPriority` | `Boolean` | Priority flag | |
|||
| `Category` | `Enum` | `VendorCategory` | |
|||
| `ComplianceScore` | `Int` | Review score | |
|||
| `Logo` | `Image` | Logo upload | |
|||
| `ComplianceDocument` | `File` | Document upload | |
|||
| `RejectionReason` | `String` | Optional | |
|||
|
|||
 |
|||
|
|||
The **Properties** tab is where the entity becomes more than a name. The table shows the field types, enum bindings, and source layer. Scroll down and the upload-related fields are visible with their `Image` and `File` types: |
|||
|
|||
 |
|||
|
|||
There is no React code yet, but we already have a lot of behavior described: required fields, uniqueness, email validation, enum fields, upload fields, and the data shape that the runtime will use. |
|||
|
|||
The `Image` and `File` types are worth calling out. They are not plain strings with a path. In the generated form they become upload controls, which is exactly what we need for vendor logos and compliance documents. |
|||
|
|||
Since `VendorApplication` is authored in the `Dev JSON` layer, it also belongs to the source-controlled model. After saving the entity metadata, create/apply the EF Core migration before you open the generated page in the runtime. This is the step that creates the backing table for the low-code entity in the database. |
|||
|
|||
## Generate a Grid Page |
|||
|
|||
The reviewers need a page where they can work with applications, so go to `Pages` and create a `dataGrid` page named `vendor-onboarding`. |
|||
|
|||
Bind it to `VendorApplication`. |
|||
|
|||
Before saving the page, the modal connects the route name, title, icon, and entity: |
|||
|
|||
 |
|||
|
|||
After the page is created, set `RequestedOn` as the default sort field, keep it descending, adjust the icon if you want, and assign `vendor-application-form` as the create/edit form: |
|||
|
|||
 |
|||
|
|||
For the review workflow, keep the configured columns focused on the fields reviewers use most: |
|||
|
|||
- Company name |
|||
- Status |
|||
- Requested date |
|||
- Priority |
|||
- Category |
|||
|
|||
Then configure the filters you want reviewers to use most often. In this workflow, the important filters are company, status, requested date, priority, and category. Depending on the runtime defaults, the generated grid may still expose additional fields such as contact email; the workflow is still driven by the focused page metadata above. |
|||
|
|||
Once the page is saved, the React runtime can resolve the route from the page metadata. The grid is generated from the entity and page configuration rather than from a hand-written React component. |
|||
|
|||
## Build the Create/Edit Form |
|||
|
|||
A grid is not enough. We also need a form that feels like the workflow. |
|||
|
|||
Go to `Forms` and create `vendor-application-form` for `VendorApplication`. Split the fields into three tabs: |
|||
|
|||
 |
|||
|
|||
- **Company**: `CompanyName`, `ContactEmail`, `Category`, `IsPriority` |
|||
- **Review**: `Status`, `RequestedOn`, `ApprovalDeadline`, `ComplianceScore`, `RejectionReason` |
|||
- **Documents**: `Logo`, `ComplianceDocument` |
|||
|
|||
Now add the conditional behavior for `RejectionReason`. In this demo I used two complementary rules: one rule shows the field when `Status = Rejected`, and the other hides it for non-rejected statuses. |
|||
|
|||
 |
|||
|
|||
This is one of the places where Low-Code becomes more than "generate a CRUD page". The runtime does more than render a static form; it evaluates the rule while the user edits the record. |
|||
|
|||
## Apply the Migration Before Opening the Runtime |
|||
|
|||
Before opening the generated page, apply the database migration for the `Dev JSON` changes. We used `Dev JSON` for `VendorApplication`, so the Designer wrote source-controlled descriptor files under `_Dynamic`. The entity shape is now part of the application model, and the database needs the matching backing table before the React runtime can save records. |
|||
|
|||
That is why `Dev JSON` is a good fit during development: the metadata files and the EF Core migration can be reviewed, committed, and reproduced in another environment. If the same entity had been created in the `Runtime JSON` layer, you would not create a C# migration for that runtime edit; the metadata change would be stored in the database instead. In practice, use `Dev JSON` for development-time, source-controlled changes, and use `Runtime JSON` when you want production-time changes to be managed from the Admin Console and persisted in the database. |
|||
|
|||
## Try It in the React Runtime |
|||
|
|||
Open the generated `vendor-onboarding` page in the React runtime and create a vendor application. |
|||
|
|||
On the `Documents` tab, the `Logo` and `ComplianceDocument` fields are rendered as upload fields: |
|||
|
|||
 |
|||
|
|||
Now edit a record and change the status to `Rejected`. The `RejectionReason` field becomes available on the `Review` tab: |
|||
|
|||
 |
|||
|
|||
After saving a few records, use the generated filters to narrow the list to rejected vendors. Depending on the runtime configuration, the filter panel can expose more fields than the small set you configured for the workflow; here we only use the `Status = Rejected` filter: |
|||
|
|||
 |
|||
|
|||
The short animation below gives a quick pass through the same runtime states: upload fields, the conditional rejection reason, and the filtered grid. |
|||
|
|||
 |
|||
|
|||
At this point we have a working page, form, validation, uploads, and filters. The important part is that all of it came from the metadata we configured in the Designer. |
|||
|
|||
## Add a Custom Summary Endpoint |
|||
|
|||
Generated CRUD is enough for day-to-day record editing, but teams often need one operation that is specific to their process. |
|||
|
|||
For vendor onboarding, a summary endpoint is a good example: |
|||
|
|||
```text |
|||
GET /api/custom/vendor-onboarding/summary |
|||
``` |
|||
|
|||
In the Designer, open `Actions` and create a custom HTTP action with that route. The script can use the [Scripting API](https://abp.io/docs/latest/low-code/scripting-api) to query the same `VendorApplication` data that the generated grid uses. |
|||
|
|||
 |
|||
|
|||
Here is the script used in the demo: |
|||
|
|||
```js |
|||
var entityName = 'Acme.VendorOnboardingLowCode.Procurement.VendorApplication'; |
|||
var vendorQuery = await db.query(entityName); |
|||
var totalVendors = await db.count(entityName); |
|||
var submittedVendors = await vendorQuery.where(x => x.Status === 0).count(); |
|||
var approvedVendors = await vendorQuery.where(x => x.Status === 2).count(); |
|||
var today = query.today || new Date().toISOString().slice(0, 10); |
|||
var overdueReviews = await vendorQuery |
|||
.where(x => x.ApprovalDeadline != null && x.ApprovalDeadline < today && x.Status !== 2) |
|||
.count(); |
|||
|
|||
return ok({ |
|||
totalVendors: totalVendors, |
|||
submittedVendors: submittedVendors, |
|||
approvedVendors: approvedVendors, |
|||
overdueReviews: overdueReviews, |
|||
evaluatedOn: today |
|||
}); |
|||
``` |
|||
|
|||
Use the entity name shown in your Designer. In the screenshots, it is `Acme.VendorOnboardingLowCode.Procurement.VendorApplication`. |
|||
|
|||
When the endpoint runs, it returns the current counts from the low-code records: |
|||
|
|||
 |
|||
|
|||
That is the bridge I like here. The page and form stay metadata-driven, but the process-specific summary is a short script exposed as a custom endpoint. |
|||
|
|||
## Add One Runtime Model |
|||
|
|||
Now switch the Designer layer to `Runtime JSON` and add one more entity: `VendorEscalation`. |
|||
|
|||
This model represents the items that need extra attention. It could have been created in the same place as `VendorApplication`; I am adding it here only to show that runtime-authored metadata participates in the same Low-Code System. |
|||
|
|||
Unlike the code and `Dev JSON` examples above, this runtime-authored model is not part of the source-controlled migration flow in this walkthrough. |
|||
|
|||
The create modal is the same Designer experience, but the selected layer is now `Runtime JSON`: |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
Create a data grid page for it and open it in the React runtime: |
|||
|
|||
 |
|||
|
|||
From the user's point of view, it behaves like the first generated page. From the metadata point of view, we have now seen code-defined metadata, Designer-authored metadata, and runtime-authored metadata in the same application. |
|||
|
|||
## Read the Same Data from ABP Code |
|||
|
|||
The last bridge is application code. |
|||
|
|||
Sometimes the generated page is not the only consumer. You may want a typed application service, a scheduled job, or another API to read the same low-code records. The code below shows the idea by returning a backlog summary: |
|||
|
|||
```csharp |
|||
private readonly IRepository<DynamicEntity, Guid> _vendorApplicationRepository; |
|||
private readonly IAsyncQueryableExecuter _queryableExecuter; |
|||
|
|||
public async Task<VendorBacklogDto> GetBacklogAsync() |
|||
{ |
|||
var entityDescriptor = DynamicModelManager.Instance.Find( |
|||
"Acme.VendorOnboardingLowCode.Procurement.VendorApplication" |
|||
); |
|||
|
|||
if (entityDescriptor == null) |
|||
{ |
|||
throw new UserFriendlyException("VendorApplication model was not found."); |
|||
} |
|||
|
|||
var query = await _vendorApplicationRepository |
|||
.SetEntityName(entityDescriptor.Name) |
|||
.GetQueryableAsync(); |
|||
var today = DateOnly.FromDateTime(Clock.Now); |
|||
var priorityQuery = query.Where(vendor => |
|||
vendor.Data["IsPriority"] != null && |
|||
(bool?)vendor.Data["IsPriority"] == true); |
|||
|
|||
var nextPriorityVendor = await _queryableExecuter.FirstOrDefaultAsync( |
|||
priorityQuery.OrderByDescending(vendor => |
|||
(DateOnly?)vendor.Data["RequestedOn"])); |
|||
|
|||
return new VendorBacklogDto |
|||
{ |
|||
TotalVendors = checked((int)await _queryableExecuter.LongCountAsync(query)), |
|||
PriorityVendors = checked((int)await _queryableExecuter.LongCountAsync(priorityQuery)), |
|||
RejectedVendors = checked((int)await _queryableExecuter.LongCountAsync( |
|||
query.Where(vendor => |
|||
vendor.Data["Status"] != null && |
|||
(int?)vendor.Data["Status"] == 3))), |
|||
OverdueReviews = checked((int)await _queryableExecuter.LongCountAsync( |
|||
query.Where(vendor => |
|||
vendor.Data["ApprovalDeadline"] != null && |
|||
(DateOnly?)vendor.Data["ApprovalDeadline"] < today && |
|||
vendor.Data["Status"] != null && |
|||
(int?)vendor.Data["Status"] != 2))), |
|||
NextPriorityVendor = nextPriorityVendor?.GetData<string>("CompanyName") |
|||
}; |
|||
} |
|||
``` |
|||
|
|||
 |
|||
|
|||
The important detail is that the aggregate operations stay on `IQueryable`; the code does not load every vendor into memory just to count them. This is not a replacement for the generated page. It is the other direction: use the generated page for the admin experience, then read the same records from normal ABP code when another part of the application needs them. |
|||
|
|||
## Going Further |
|||
|
|||
The workflow we built is intentionally focused, but the same shape can grow in a few directions: |
|||
|
|||
- Add permissions around the generated pages and custom endpoint. |
|||
- Add more form rules for review-specific fields. |
|||
- Add an approval notification after a vendor is accepted. |
|||
- Add a scheduled job that checks overdue applications. |
|||
- Build a dashboard widget on top of the summary endpoint. |
|||
|
|||
The main pattern stays the same: model the data in the Low-Code Designer, let the React runtime render the operational page, and add code or scripting only for the parts that are specific to your business process. |
|||
|
|||
## Conclusion |
|||
|
|||
ABP Low-Code is useful when the first version of a business workflow is mostly metadata: entities, fields, filters, forms, validation, uploads, and a few custom actions. |
|||
|
|||
In this vendor onboarding example, the `VendorApplication` model gave us a generated grid and form, the runtime handled upload fields and conditional UI, and a custom endpoint added the summary that CRUD would not provide by itself. We also saw that low-code metadata can come from the Designer, from runtime JSON, or from C# code when you need that bridge. |
|||
|
|||
That is the part worth remembering: you can start with a working admin experience quickly, then extend the workflow where the generated behavior stops being enough. |
|||
|
|||
### Further Reading |
|||
|
|||
- [Low-Code System Overview](https://abp.io/docs/latest/low-code/index) |
|||
- [Low-Code Designer](https://abp.io/docs/latest/low-code/designer) |
|||
- [React Runtime](https://abp.io/docs/latest/low-code/react-runtime) |
|||
- [Custom Endpoints](https://abp.io/docs/latest/low-code/custom-endpoints) |
|||
- [Scripting API](https://abp.io/docs/latest/low-code/scripting-api) |
|||
@ -0,0 +1 @@ |
|||
Build a vendor onboarding workflow with ABP Low-Code: model vendor applications in the Designer, let the React runtime render the grid and form, then add a custom endpoint and a typed ABP code bridge for process-level counts. |
|||
|
After Width: | Height: | Size: 252 KiB |
|
After Width: | Height: | Size: 974 KiB |
|
After Width: | Height: | Size: 165 KiB |
|
After Width: | Height: | Size: 12 MiB |
|
After Width: | Height: | Size: 403 KiB |
|
After Width: | Height: | Size: 31 KiB |
|
After Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 33 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 104 KiB |
@ -0,0 +1,225 @@ |
|||
# Introducing ABP Low-Code: Build Real ABP Apps in Minutes |
|||
|
|||
**Create runtime-managed pages, generated React screens, code-first C# entities, and Script API extensions without leaving the ABP application model.** |
|||
|
|||
 |
|||
|
|||
> **Want to try the same path?** Start from ABP Studio, enable the Low-Code runtime and designer, define pages in the Admin Console, and see them resolve inside the running ABP app. |
|||
|
|||
--- |
|||
|
|||
## ABP Low-Code at a glance |
|||
|
|||
| Runtime authoring | Generated screens | ABP-native extensibility | One application model | |
|||
| :---: | :---: | :---: | :---: | |
|||
| Define and update pages in the Admin Console | Grid, Form, Calendar, Kanban, Gallery, Dashboard | Code-first entities, Script API actions, and C# query paths | Runtime metadata, generated UI, and application code stay together | |
|||
|
|||
--- |
|||
|
|||
## Built into the ABP Platform |
|||
|
|||
Low-code is most useful when speed does not create a separate stack to maintain later. |
|||
|
|||
That is where many low-code products start to strain. They move quickly at the beginning, then force a second implementation track when the app needs permissions, auditability, custom logic, or tighter integration with existing application code. |
|||
|
|||
ABP Low-Code takes a different path. It runs **inside the ABP Platform**, so runtime-managed pages are part of an application foundation that already includes identity, permissions, audit logging, APIs, and code-level extensibility. |
|||
|
|||
--- |
|||
|
|||
## Edit at runtime. See it in the app. |
|||
|
|||
In the Low-Code Designer, you update a runtime-managed page. A few seconds later, the same application surface is visible in the live app. No rebuild loop. No parallel front-end implementation. No "we will wire it later" gap between authoring and runtime. |
|||
|
|||
ABP Low-Code shortens the cycle from model change to running screen while keeping the output grounded in the same ABP application. |
|||
|
|||
 |
|||
|
|||
> **What this shows:** authoring and runtime are connected. Pages are defined in the designer and resolved in the running application. |
|||
|
|||
--- |
|||
|
|||
## CRUD is table stakes |
|||
|
|||
If low-code only saves you from drawing a table and a form, it is not enough. Business applications need richer operational surfaces. |
|||
|
|||
In the generated app, the `Events` screen ships with search, actions, filters, and form-driven editing. The form structure already understands tabs, relations, validation, and business-shaped input instead of leaving you with a blank shell to finish by hand. |
|||
|
|||
 |
|||
|
|||
The point is not just generated CRUD. It is generated CRUD that already looks like the operational screens teams maintain in real applications. |
|||
|
|||
--- |
|||
|
|||
## One model, multiple operational screens |
|||
|
|||
Business users do not think in one view. Operators want a calendar for scheduling, a kanban board for workflow, a grid for bulk operations, a gallery when media matters, and a dashboard when they need the state of the business at a glance. |
|||
|
|||
ABP Low-Code keeps those surfaces attached to the same underlying model. The same `Session` model can appear as a **calendar** for planning and a **kanban pipeline** for operational flow. The same generated app can also include a **speaker gallery** and an **overview dashboard** for metrics. |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
This is where ABP Low-Code starts to feel less like a form generator and more like a runtime application layer: one model, many working screens, no second implementation track for each view type. |
|||
|
|||
--- |
|||
|
|||
## When low-code needs code |
|||
|
|||
The real differentiator is not that ABP Low-Code can go fast. It is that **speed does not require isolation from the application foundation**. |
|||
|
|||
When generated CRUD is not enough, you extend the same app instead of throwing the low-code layer away. |
|||
|
|||
ABP Low-Code exposes a server-side **Script API** inside the same application model. That scripting surface can back: |
|||
|
|||
- **Custom endpoints** when the UI needs an API-shaped response. |
|||
- **Interceptors** when create or update commands need validation or mutation. |
|||
- **Event handlers** when logic should react to runtime events. |
|||
- **Background jobs** when work should continue asynchronously. |
|||
- **Background workers** when operational logic should run on a schedule. |
|||
|
|||
In this article, the visible proof happens to be `GET /api/custom/eventflow/highlights`. The GIF shows an endpoint because it is the easiest proof surface to read. But the broader point is that endpoints are only one consumer of the same low-code scripting layer. |
|||
|
|||
That hybrid model matters in both directions: |
|||
|
|||
- **Code-first ABP entities can be surfaced in low-code flows and runtime pages.** |
|||
- **Low-code-managed data and screens stay reachable from Script API actions, application services, repository queries, and custom endpoints.** |
|||
- **Teams do not lose architectural control just because they gained a faster authoring layer.** |
|||
|
|||
 |
|||
|
|||
The actual capability is the shared ABP application model behind it: script when runtime logic is enough, C# when typed application services and repository queries are the better fit. |
|||
|
|||
This is the difference between "low-code as a shortcut" and "low-code as part of your application platform." |
|||
|
|||
--- |
|||
|
|||
## From code-first entity to generated page |
|||
|
|||
The first direction is code-first to low-code. A **code-first** `SponsorActivation` entity checked into the ASP.NET Core project can still become a working runtime page without forking into a separate low-code-only model. |
|||
|
|||
The code-first entity carries the same metadata that ABP Low-Code uses to generate the page: |
|||
|
|||
```csharp |
|||
[DynamicEntity(DefaultDisplayPropertyName = nameof(CompanyName))] |
|||
[DynamicEntityUI("Sponsor Activations")] |
|||
[DynamicEntityAttachments("application/pdf", "image/*", MaxFileCount = 4)] |
|||
public class SponsorActivation : DynamicEntityBase |
|||
{ |
|||
[Required] |
|||
[DynamicPropertyUI(DisplayName = "Sponsor")] |
|||
public string CompanyName { get; private set; } |
|||
|
|||
[Required] |
|||
[EmailAddress] |
|||
[DynamicPropertyUI(DisplayName = "Contact Email")] |
|||
public string ContactEmail { get; private set; } |
|||
|
|||
public SponsorActivationStatus Status { get; set; } |
|||
|
|||
[DynamicForeignKey("EventFlow.Events.Event", "Title")] |
|||
public Guid? EventId { get; set; } |
|||
|
|||
[DynamicForeignKey("Volo.Abp.Identity.IdentityUser", nameof(IdentityUser.UserName), ForeignAccess.View)] |
|||
public Guid? OwnerUserId { get; set; } |
|||
|
|||
[DynamicPropertyType(EntityPropertyType.Money)] |
|||
public decimal ActivationBudget { get; set; } |
|||
|
|||
[DynamicPropertyImageOptions("image/png", "image/jpeg")] |
|||
public string? BrandLogo { get; set; } |
|||
|
|||
[DynamicPropertyFileOptions("application/pdf", ".pptx", ".docx")] |
|||
public string? ActivationBrief { get; set; } |
|||
} |
|||
``` |
|||
|
|||
That class lives as normal C# source, gets migrated like the rest of the application, and is seeded with real records so the runtime page does not open as an empty shell. |
|||
|
|||
Inside the designer, selecting the `SponsorActivation` entity auto-generates the page identity, binds the grid to the entity, and lands on a real runtime route at `/dynamic/sponsor-activation`. The generated surface includes sponsor, email, event lookup, owner lookup, budget, image, and file fields directly from the C# model. |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
That is the distinction that matters: code-first ABP entities can move through low-code without becoming throwaway artifacts, and low-code-generated surfaces remain part of the same application story. |
|||
|
|||
--- |
|||
|
|||
## Low-code data stays reachable from C# |
|||
|
|||
The bridge also works in the other direction. A normal ABP application service can query a low-code model through `IRepository<DynamicEntity, Guid>`, apply real filters, and combine that result with code-first aggregates. |
|||
|
|||
The service behind the endpoint in the previous section looks like this: |
|||
|
|||
```csharp |
|||
public async Task<EventFlowLowCodeProofDto> GetHybridSummaryAsync() |
|||
{ |
|||
var liveSessionQuery = (await _dynamicEntityRepository |
|||
.SetEntityName("EventFlow.Events.Session") |
|||
.GetQueryableAsync()) |
|||
.Where("int(it[\"Status\"]) == @0", 2); |
|||
|
|||
var publicSessionQuery = liveSessionQuery |
|||
.Where("bool(it[\"IsPublic\"]) == @0", true); |
|||
|
|||
var sponsorQuery = (await _sponsorActivationRepository.GetQueryableAsync()) |
|||
.Where(activation => |
|||
activation.Status == SponsorActivationStatus.Approved || |
|||
activation.Status == SponsorActivationStatus.Live); |
|||
|
|||
var liveSessionCount = await AsyncExecuter.CountAsync(liveSessionQuery); |
|||
var publicSessionCount = await AsyncExecuter.CountAsync(publicSessionQuery); |
|||
var activeSponsorActivationCount = await AsyncExecuter.CountAsync(sponsorQuery); |
|||
|
|||
return new EventFlowLowCodeProofDto |
|||
{ |
|||
LiveSessionCount = liveSessionCount, |
|||
PublicSessionCount = publicSessionCount, |
|||
ActiveSponsorActivationCount = activeSponsorActivationCount |
|||
}; |
|||
} |
|||
``` |
|||
|
|||
Here, low-code-managed `Session` rows are filtered from C# with real `Where(...)` clauses, then combined with the typed `SponsorActivation` repository. The endpoint and dashboard are just one presentation surface for that shared ABP query path. |
|||
|
|||
That is the ABP difference: low-code data stays reachable from code, and code-first entities stay reachable from low-code. |
|||
|
|||
--- |
|||
|
|||
## Why ABP Low-Code matters |
|||
|
|||
The value is not novelty. It is a faster way to build real business applications without separating speed from the application foundation. |
|||
|
|||
- **Speed without replatforming.** Runtime-managed screens reduce delivery time without moving the team onto a separate application stack. |
|||
- **Governance without friction.** Permissions, identity, auditability, and ABP platform foundations stay part of the story from day one. |
|||
- **Extensibility without rewrite pressure.** When custom behavior shows up, the same application can be extended instead of replacing the low-code output. |
|||
|
|||
That is the core ABP Low-Code promise: faster delivery, still inside the application model you can extend. |
|||
|
|||
--- |
|||
|
|||
## Try it yourself |
|||
|
|||
The public starting point for ABP Low-Code is **ABP Studio**. |
|||
|
|||
 |
|||
|
|||
1. Open **ABP Studio** and create a new solution. |
|||
2. In the solution wizard, enable **Include Low-Code runtime and designer**. |
|||
3. Complete the wizard, then run the generated backend and React UI from the solution. |
|||
4. Sign in with the administrator account created for that solution. |
|||
5. Open **Admin Console** to define runtime-managed entities, forms, pages, permissions, endpoints, and script actions. |
|||
6. Switch to the application side to see those changes resolve live in the running app. |
|||
|
|||
--- |
|||
|
|||
## Further reading |
|||
|
|||
- [ABP Low-Code Designer Documentation](https://abp.io/docs/latest/low-code/designer) |
|||
- [ABP Low-Code Configuration & Fluent API](https://abp.io/docs/latest/low-code/fluent-api) |
|||
- [ABP Low-Code Scripting API](https://abp.io/docs/latest/low-code/scripting-api) |
|||
- [ABP Low-Code Script Actions](https://abp.io/docs/latest/low-code/script-actions) |
|||
- [ABP Low-Code Interceptors](https://abp.io/docs/latest/low-code/interceptors) |
|||
- [ABP Studio Documentation](https://abp.io/docs/latest/studio) |
|||
- [Get Started with ABP: Creating a Layered Web Application](https://abp.io/docs/latest/get-started/layered-web-application) |
|||
@ -0,0 +1 @@ |
|||
Discover how ABP Low-Code blends runtime page building with code-first entities, C# queries, and extensible application logic. |
|||
@ -0,0 +1,116 @@ |
|||
```json |
|||
//[doc-seo] |
|||
{ |
|||
"Description": "Upgrade your ABP solutions to Angular version 22.0.x" |
|||
} |
|||
``` |
|||
|
|||
# Release Notes: Angular 22 and TypeScript 6 Upgrade |
|||
|
|||
## Overview |
|||
|
|||
This release updates ABP Angular UI applications to: |
|||
|
|||
* Angular `22.x` |
|||
* TypeScript `6.x` |
|||
|
|||
This upgrade aligns ABP projects with the latest Angular ecosystem and provides access to the newest framework improvements while ensuring long-term maintainability and support. |
|||
|
|||
## What's Changed |
|||
|
|||
### 1. Frontend Stack Upgrades |
|||
|
|||
The core frontend stack has been updated: |
|||
|
|||
* `@angular/*` packages have been upgraded to version 22 |
|||
* `typescript` has been upgraded to version 6 |
|||
* ABP and ABP Commercial npm packages must be upgraded to the corresponding ABP release line (version 10.6) |
|||
|
|||
### 2. Change Detection Behavior |
|||
|
|||
Angular 22 introduces updated change detection behavior. |
|||
|
|||
* Components without explicit change detection configuration now follow OnPush-style behavior by default |
|||
* Some existing pages may no longer update automatically after asynchronous operations |
|||
* UI state should be managed using Angular Signals or the `async` pipe where appropriate |
|||
|
|||
### 3. Stricter Type and Template Checks |
|||
|
|||
Angular 22 and TypeScript 6 introduce additional compile-time validations. |
|||
|
|||
* More template and type-related issues may be reported during builds |
|||
* Existing assumptions around nullable values and optional properties may require additional guards or type refinements |
|||
* Applications with strict template checking enabled may require code updates |
|||
|
|||
### 4. Upload Progress Handling |
|||
|
|||
Applications that rely on file upload progress events may require additional HTTP client configuration. |
|||
|
|||
* Browser-side HTTP configuration may need `withXhr()` enabled to ensure upload progress events are emitted correctly |
|||
|
|||
### 5. Chart Update Behavior |
|||
|
|||
Chart components may require additional updates when used with asynchronous data sources. |
|||
|
|||
* Under OnPush-style change detection, chart updates may not be detected automatically |
|||
* Consider using Signals for chart data bindings |
|||
* Calling `reinit()` after asynchronous data updates may be necessary in some scenarios |
|||
|
|||
## Required Actions |
|||
|
|||
### 1. Upgrade Related Packages Together |
|||
|
|||
Keep Angular, TypeScript, ABP, and ABP Commercial packages on compatible versions. |
|||
|
|||
To use Angular 22: |
|||
|
|||
* Angular: `22.x` |
|||
* TypeScript: `6.x` |
|||
* ABP Framework: `10.6.x` |
|||
|
|||
### 2. Review UI State Management |
|||
|
|||
Review pages that depend on asynchronous state updates, including: |
|||
|
|||
* List and table data |
|||
* Loading and busy indicators |
|||
* Modal dialog state |
|||
* Dashboard and chart data |
|||
|
|||
Consider migrating these scenarios to Angular Signals or the `async` pipe. |
|||
|
|||
### 3. Apply a Temporary TypeScript Compatibility Setting (If Needed) |
|||
|
|||
If your project uses `downlevelIteration`, you may temporarily add the following configuration: |
|||
|
|||
```json |
|||
{ |
|||
"ignoreDeprecations": "6.0" |
|||
} |
|||
``` |
|||
|
|||
This can help ease the migration process while addressing TypeScript 6 deprecation warnings. |
|||
|
|||
### 4. Perform Regression Testing |
|||
|
|||
We recommend validating all critical application flows after upgrading, including: |
|||
|
|||
* Authentication and account management pages |
|||
* CRUD list and detail pages |
|||
* Permission and feature management dialogs |
|||
* File upload workflows |
|||
* Dashboard and chart components |
|||
|
|||
## Areas to Validate Carefully |
|||
|
|||
Pay particular attention to the following scenarios: |
|||
|
|||
* Busy or loading indicators not updating correctly |
|||
* Modal open/close state inconsistencies |
|||
* List pages not refreshing after asynchronous operations |
|||
* Upload progress events not being emitted |
|||
* Charts rendering without data after API responses |
|||
|
|||
## References |
|||
|
|||
* Detailed migration guide: [Upgrade ABP to 10.6](../../../../release-info/migration-guides/abp-10-6-angular-22.md) |
|||
@ -0,0 +1,193 @@ |
|||
```json |
|||
//[doc-seo] |
|||
{ |
|||
"Description": "Upgrade your ABP solutions to Angular version 22.0.x" |
|||
} |
|||
``` |
|||
|
|||
# Angular 22 and ABP 10.6 Upgrade Guide |
|||
|
|||
This guide explains how to upgrade ABP Angular applications to **Angular 22** and **TypeScript 6**. |
|||
|
|||
## 1. Target Versions |
|||
|
|||
Update all frontend dependencies together to maintain compatibility: |
|||
|
|||
- `@angular/*` → `~22.0.0` |
|||
- `typescript` → `~6.0.0` |
|||
- `@abp/*` → corresponding ABP version (10.6) |
|||
- `@volo/*`, `@volosoft/*` (if applicable) → corresponding ABP version (10.6) |
|||
- `angular-oauth2-oidc` (if applicable) → `~22.0.0` |
|||
|
|||
Avoid mixing Angular 21 and Angular 22 packages within the same workspace. |
|||
|
|||
## 2. Prerequisites |
|||
|
|||
Before starting the upgrade: |
|||
|
|||
1. Use a Node.js version supported by Angular 22. |
|||
2. Ensure your backend ABP version is compatible with the frontend package versions you plan to install. |
|||
3. Commit or back up your current project state. |
|||
|
|||
## 3. Upgrade Process |
|||
|
|||
1. Update package versions in `package.json`. |
|||
2. Run the Angular or Nx migration commands applicable to your project. |
|||
3. Remove existing installation artifacts: |
|||
- Delete `node_modules` |
|||
- Delete the lock file (`package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml`) |
|||
|
|||
4. Reinstall all dependencies. |
|||
5. Build the application and resolve any compilation or template errors. |
|||
|
|||
## 4. Required Changes |
|||
|
|||
### 4.1 TypeScript 6 Deprecation Handling |
|||
|
|||
Projects that still use `downlevelIteration: true` may encounter TypeScript 6 deprecation diagnostics. |
|||
|
|||
Add the following temporary setting to your root `tsconfig` file (and library production configurations if required): |
|||
|
|||
```json |
|||
{ |
|||
"compilerOptions": { |
|||
"downlevelIteration": true, |
|||
"ignoreDeprecations": "6.0" |
|||
} |
|||
} |
|||
``` |
|||
|
|||
As a long-term solution, remove `downlevelIteration` when your target runtime environment no longer requires it. |
|||
|
|||
### 4.2 Updated Change Detection Behavior |
|||
|
|||
Angular 22 introduces updated change detection behavior for components that do not explicitly configure a change detection strategy. |
|||
|
|||
Common symptoms include: |
|||
|
|||
- Loading indicators not updating |
|||
- Modal busy states not clearing |
|||
- Lists or charts not refreshing after asynchronous operations |
|||
|
|||
Recommended approaches: |
|||
|
|||
1. Use `signal()` for component state. |
|||
2. Use `toSignal()` when consuming observable streams. |
|||
3. Use the `async` pipe for observable-based UI state. |
|||
4. Use `ChangeDetectionStrategy.Eager` only as a temporary compatibility measure for legacy components. |
|||
|
|||
### 4.3 ABP List Pages (`ListService`) |
|||
|
|||
When working with `ListService`, prefer converting observable results to signals instead of manually subscribing. |
|||
|
|||
```typescript |
|||
readonly data = toSignal( |
|||
this.list.hookToQuery(query => this.service.getList(query)), |
|||
{ initialValue: { items: [], totalCount: 0 } }, |
|||
); |
|||
``` |
|||
|
|||
Update template bindings accordingly: |
|||
|
|||
- `data.items` → `data().items` |
|||
- `data.totalCount` → `data().totalCount` |
|||
|
|||
### 4.4 Modals and Loading States |
|||
|
|||
For components such as `abp-modal`, `abp-button`, and permission or feature management dialogs, maintain state using signals. |
|||
|
|||
```typescript |
|||
readonly isModalVisible = signal(false); |
|||
readonly modalBusy = signal(false); |
|||
``` |
|||
|
|||
```html |
|||
<abp-button [loading]="modalBusy()" /> |
|||
<abp-modal |
|||
[visible]="isModalVisible()" |
|||
(visibleChange)="isModalVisible.set($event)" |
|||
[busy]="modalBusy()" |
|||
/> |
|||
``` |
|||
|
|||
If you use `*abpReplaceableTemplate`, pass signal values through `inputs.value` and update state through the corresponding event callbacks. |
|||
|
|||
### 4.5 Template Type Checking |
|||
|
|||
Angular 22 enables `strictTemplates` by default. |
|||
|
|||
Resolve template typing issues where possible, or temporarily disable strict template checking: |
|||
|
|||
```json |
|||
{ |
|||
"angularCompilerOptions": { |
|||
"strictTemplates": false |
|||
} |
|||
} |
|||
``` |
|||
|
|||
Common adjustments include: |
|||
|
|||
- Updating optional chaining (`?.`) and null coalescing (`??`) usage |
|||
- Guarding optional form references before binding |
|||
- Resolving duplicate input or output bindings |
|||
|
|||
### 4.6 Upload Progress Events |
|||
|
|||
Applications that rely on upload progress events should include the XHR backend in browser-side HTTP configuration: |
|||
|
|||
```typescript |
|||
provideHttpClient(withFetch(), withXhr()); |
|||
``` |
|||
|
|||
Do not enable the XHR backend in server-side rendering (SSR) bootstrap code. |
|||
|
|||
### 4.7 Chart Components (`abp-chart`) |
|||
|
|||
If charts do not update after asynchronous data loading: |
|||
|
|||
- Store chart data in a signal |
|||
- Bind chart inputs using signal values (for example, `[data]="chartData()"`) |
|||
- Call `reinit()` after assigning new data rather than relying solely on `refresh()` |
|||
|
|||
## 5. Custom or Forked UI Modules |
|||
|
|||
If your project contains customized copies of ABP modules such as Identity, Tenant Management, Account, or CMS Kit: |
|||
|
|||
1. Compare your implementation with the updated package versions. |
|||
2. Apply the recommended signal-based state management patterns. |
|||
3. Re-test CRUD pages, permission dialogs, feature dialogs, and account-related workflows. |
|||
|
|||
## 6. Validation Checklist |
|||
|
|||
After completing the upgrade, verify that: |
|||
|
|||
- Dependencies are installed correctly without duplicate Angular versions |
|||
- The application builds successfully |
|||
- Unit tests pass (if applicable) |
|||
- Login, registration, and password recovery workflows function correctly |
|||
- CRUD list pages refresh as expected |
|||
- Modal loading and busy states behave correctly |
|||
- Permission and feature dialogs open and close correctly |
|||
- Upload progress events work as expected (if applicable) |
|||
- Dashboard charts render correctly after data is loaded |
|||
|
|||
## 7. Troubleshooting |
|||
|
|||
| Symptom | Likely Cause | Resolution | |
|||
| ----------------------------------------------------------------- | ----------------------------------------- | ----------------------------------------------------------- | |
|||
| Form type conflicts (`AbstractControl`, etc.) | Multiple Angular versions installed | Align package versions and perform a clean reinstall | |
|||
| TypeScript deprecation errors related to `downlevelIteration` | TypeScript 6 diagnostics | Add `ignoreDeprecations: "6.0"` temporarily | |
|||
| Errors involving optional configuration or environment properties | Stricter type checking | Add null checks and optional chaining where appropriate | |
|||
| DTO or library compilation issues | Type incompatibilities in DTO definitions | Prefer interfaces and optional properties where appropriate | |
|||
| Upload progress events are not emitted | Missing XHR backend configuration | Add `withXhr()` to browser-side HTTP configuration | |
|||
| Charts remain empty after data loads | State changes are not being detected | Use signals and call `reinit()` after updating chart data | |
|||
|
|||
## 8. Summary |
|||
|
|||
When upgrading to Angular 22, focus on the following areas: |
|||
|
|||
1. Upgrade Angular, TypeScript, ABP, and commercial packages together. |
|||
2. Update UI state management to use signals, `toSignal()`, or the `async` pipe where appropriate. |
|||
3. Resolve TypeScript 6 and template type-checking issues. |
|||
4. Validate critical application workflows, including modals, list pages, uploads, and chart components. |
|||
@ -0,0 +1,237 @@ |
|||
```json |
|||
//[doc-seo] |
|||
{ |
|||
"Description": "Upgrade your ABP solutions from v10.5 to v10.6 with this migration guide covering important behavior and integration changes." |
|||
} |
|||
``` |
|||
|
|||
# ABP Version 10.6 Migration Guide |
|||
|
|||
This document is a guide for upgrading ABP v10.5 solutions to ABP v10.6. There are some important changes that may require action in specific application scenarios. |
|||
|
|||
> **Package Version Changes:** Before upgrading, review the [Package Version Changes](../../package-version-changes.md) document to see version changes on dependent NuGet and NPM packages and align your project with ABP's internal package versions. |
|||
|
|||
## Open-Source (Framework) |
|||
|
|||
This version contains the following changes on the open-source side: |
|||
|
|||
### Background Jobs Infrastructure Extensions |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using the default background job worker and wanting dedicated workers, parallel execution, or successful job retention. |
|||
- Applications with a custom `IBackgroundJobStore` implementation. |
|||
- Applications using the Background Jobs module with EF Core and enabling successful job retention. |
|||
|
|||
**What changed** |
|||
|
|||
- ABP adds opt-in support for: |
|||
- storing successfully completed jobs (`StoreSuccessfulJobs`) |
|||
- dedicated workers per job argument type (`AddDedicatedWorker(...)`) |
|||
- parallel job execution (`MaxParallelJobExecutionCount`) |
|||
- `IBackgroundJobStore`, `IBackgroundJobWorker`, and related infrastructure gained new members. |
|||
- EF Core stores add a `CompletionTime` column to background job records for retention scenarios. |
|||
- All new runtime features are disabled by default. |
|||
|
|||
**What to do** |
|||
|
|||
No action is required if you do not enable the new options and do not maintain a custom background job store. |
|||
|
|||
If you maintain a custom `IBackgroundJobStore`, implement the new interface members so your solution compiles. |
|||
|
|||
If you enable `StoreSuccessfulJobs`, add/review the EF Core migration for the `CompletionTime` column and configure retention options explicitly: |
|||
|
|||
```csharp |
|||
Configure<AbpBackgroundJobWorkerOptions>(options => |
|||
{ |
|||
options.StoreSuccessfulJobs = true; |
|||
options.SuccessfulJobRetentionTime = TimeSpan.FromDays(7); |
|||
}); |
|||
``` |
|||
|
|||
If you enable dedicated workers or parallel execution, configure the options consistently across all application instances and use a real distributed lock provider in clustered deployments. |
|||
|
|||
> See the [Background Jobs](../../framework/infrastructure/background-jobs/index.md) document and [#25742](https://github.com/abpframework/abp/pull/25742) for details. |
|||
|
|||
### API Definition and Proxy Generation for Uploads and Content Types |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using generated Angular, jQuery, or C# proxies for upload endpoints. |
|||
- Applications returning non-JSON response types from application services. |
|||
- Applications that customized generated upload proxy signatures. |
|||
|
|||
**What changed** |
|||
|
|||
- API definition now exposes response `ContentTypes` and `IsRemoteStream`. |
|||
- Generated Angular and jQuery proxies forward upload DTOs containing `IRemoteStreamContent` as multipart `FormData`. |
|||
- Generated Angular upload method signatures may collapse the upload argument to `FormData`. |
|||
- `RestService` now unwraps ABP error envelopes more consistently for text and blob response modes. |
|||
|
|||
**What to do** |
|||
|
|||
- Keep upload DTO types in `FormBodyBindingIgnoredTypes` as before. |
|||
- Regenerate client proxies after upgrading. |
|||
- Update custom client code that assumed upload proxies accepted the original DTO type instead of `FormData`. |
|||
- Re-test file upload flows in Angular, MVC/jQuery, and C# client integrations. |
|||
|
|||
> See [#25639](https://github.com/abpframework/abp/pull/25639) for details. |
|||
|
|||
### Angular 22 Upgrade |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using the ABP Angular UI. |
|||
- Applications with custom Angular code, third-party Angular libraries, or CI pipelines pinned to Angular 21. |
|||
|
|||
**What changed** |
|||
|
|||
- ABP Angular packages and templates now target **Angular 22.0.x**. |
|||
- Locale loading was improved with a fallback mechanism for missing or partial locale resources. |
|||
|
|||
**What to do** |
|||
|
|||
- Upgrade your Angular application dependencies together with ABP NPM packages. |
|||
- Follow the official Angular update guidance for your current Angular version. |
|||
- Re-run UI tests and rebuild custom Angular libraries after the upgrade. |
|||
- Regenerate Angular proxies after upgrading backend packages. |
|||
|
|||
> See [#25690](https://github.com/abpframework/abp/pull/25690) and [#25734](https://github.com/abpframework/abp/pull/25734) for details. |
|||
|
|||
### Antiforgery User Id Claim Issuer Normalization |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications that serve a token-authenticated SPA and cookie-authenticated MVC/Razor Pages on the same origin. |
|||
- Applications using Razor Pages modules such as Setting Management with antiforgery-protected POST handlers. |
|||
|
|||
**What changed** |
|||
|
|||
- ABP normalizes the user id claim issuer while generating and validating antiforgery tokens. |
|||
- Razor Pages now use ABP's antiforgery validation path instead of only the built-in ASP.NET Core filter. |
|||
- The behavior is enabled by default through `AbpAntiForgeryOptions.NormalizeUserIdClaimIssuer`. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test SPA + MVC mixed authentication flows, especially pages that POST immediately on load. |
|||
- If you implemented custom antiforgery logic that depends on the raw claim issuer, review it after upgrading. |
|||
- Disable the behavior only if you intentionally rely on the previous issuer-specific antiforgery identity: |
|||
|
|||
```csharp |
|||
Configure<AbpAntiForgeryOptions>(options => |
|||
{ |
|||
options.NormalizeUserIdClaimIssuer = false; |
|||
}); |
|||
``` |
|||
|
|||
> See [#25655](https://github.com/abpframework/abp/pull/25655) and [#25669](https://github.com/abpframework/abp/pull/25669) for details. |
|||
|
|||
### OpenIddict Interactive Cookie `client_id` Fix |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using OpenIddict authorization-code flows together with interactive cookie authentication. |
|||
- Applications relying on audit logs or current-client resolution from cookie-authenticated requests. |
|||
|
|||
**What changed** |
|||
|
|||
- ABP removes `client_id` from the interactive authentication cookie when the cookie principal is refreshed. |
|||
- Access tokens are unaffected. |
|||
- Cookies that were already corrupted self-heal on the next refresh. |
|||
|
|||
**What to do** |
|||
|
|||
No action is required. Re-test authorization, account, and audit-log scenarios if you previously observed intermittent incorrect `ClientId` values in cookie-authenticated requests. |
|||
|
|||
> See [#25711](https://github.com/abpframework/abp/pull/25711) for details. |
|||
|
|||
### Access Token Forwarding for Authenticated Client Requests |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using `HttpContextAbpAccessTokenProvider`. |
|||
- Machine-to-machine integrations that authenticate with `client_credentials` and then call other protected APIs from the same request pipeline. |
|||
|
|||
**What changed** |
|||
|
|||
- The provider now forwards the incoming access token whenever the request is authenticated, not only when there is an interactive user. |
|||
- `client_credentials` requests no longer fall back to configured identity clients in that scenario. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test service-to-service calls that rely on the current HTTP context access token. |
|||
- Verify downstream API authorization when the caller authenticates as a client rather than a user. |
|||
|
|||
> See [#25740](https://github.com/abpframework/abp/pull/25740) for details. |
|||
|
|||
### Thread Current Principal Accessor Behavior |
|||
|
|||
**Who is affected** |
|||
|
|||
- Background jobs, hosted services, and other non-web code that reads `ICurrentPrincipalAccessor.Principal`. |
|||
- Code that explicitly checks for `null` principals in non-web contexts. |
|||
|
|||
**What changed** |
|||
|
|||
- `ThreadCurrentPrincipalAccessor` now returns an anonymous `ClaimsPrincipal` instead of `null` when `Thread.CurrentPrincipal` is not set. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test background jobs and hosted services that branch on `Principal == null`. |
|||
- Prefer checking authentication/identity state through claims or ABP's current user/client abstractions instead of relying on a `null` principal. |
|||
|
|||
> See [#25752](https://github.com/abpframework/abp/pull/25752) for details. |
|||
|
|||
### Dependency Updates |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications that pin ABP transitive dependencies directly. |
|||
- Applications using `Microsoft.Data.SqlClient`, Swashbuckle, or Angular with fixed versions. |
|||
|
|||
**What changed** |
|||
|
|||
- `Microsoft.*` and `System.*` packages were upgraded to **10.0.9**. |
|||
- `Microsoft.Data.SqlClient` was upgraded to **7.0.2**. |
|||
- `Swashbuckle.AspNetCore` was upgraded to **10.2.3**. |
|||
- ABP Angular packages were upgraded to **Angular 22.0.x**. |
|||
|
|||
**What to do** |
|||
|
|||
- Review your direct package references and align them with ABP's package versions where needed. |
|||
- Rebuild and run database/integration tests if you directly use `Microsoft.Data.SqlClient`. |
|||
- Re-test Swagger/OpenAPI integration if you customized Swashbuckle configuration. |
|||
|
|||
## Pro |
|||
|
|||
There are no explicitly marked breaking changes on the PRO side in this release scope. However, check the following if they apply to your application. |
|||
|
|||
### OpenIddict Generate Access Token UI |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using OpenIddict application management UIs in ABP Commercial. |
|||
|
|||
**What changed** |
|||
|
|||
- Administrators can generate access tokens for OpenIddict applications from MVC, Blazor, MudBlazor, and Angular UIs. |
|||
- The backend forwards `client_credentials` requests to `/connect/token`. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test OpenIddict application administration pages after upgrading. |
|||
- Review who can access the new token-generation action in your authorization setup. |
|||
|
|||
### AI Management Indexing Resilience |
|||
|
|||
**Who is affected** |
|||
|
|||
- Applications using the AI Management module with document indexing enabled. |
|||
|
|||
**What changed** |
|||
|
|||
- Indexing is more resilient under memory pressure. |
|||
|
|||
**What to do** |
|||
|
|||
- Re-test document indexing on large datasets or memory-constrained environments after upgrading. |
|||
@ -0,0 +1,66 @@ |
|||
using System.Threading.Tasks; |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.Options; |
|||
using Volo.Abp.BackgroundWorkers; |
|||
using Volo.Abp.DistributedLocking; |
|||
using Volo.Abp.Threading; |
|||
using Volo.Abp.Timing; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
/// <summary>
|
|||
/// Periodically deletes retained successfully completed jobs older than
|
|||
/// <see cref="AbpBackgroundJobWorkerOptions.SuccessfulJobRetentionTime"/>.
|
|||
/// Only relevant when <see cref="AbpBackgroundJobWorkerOptions.StoreSuccessfulJobs"/> is enabled.
|
|||
/// </summary>
|
|||
public class BackgroundJobCleanupWorker : AsyncPeriodicBackgroundWorkerBase |
|||
{ |
|||
protected AbpBackgroundJobOptions JobOptions { get; } |
|||
|
|||
protected AbpBackgroundJobWorkerOptions WorkerOptions { get; } |
|||
|
|||
protected IAbpDistributedLock DistributedLock { get; } |
|||
|
|||
public BackgroundJobCleanupWorker( |
|||
AbpAsyncTimer timer, |
|||
IServiceScopeFactory serviceScopeFactory, |
|||
IOptions<AbpBackgroundJobOptions> jobOptions, |
|||
IOptions<AbpBackgroundJobWorkerOptions> workerOptions, |
|||
IAbpDistributedLock distributedLock) |
|||
: base(timer, serviceScopeFactory) |
|||
{ |
|||
JobOptions = jobOptions.Value; |
|||
WorkerOptions = workerOptions.Value; |
|||
DistributedLock = distributedLock; |
|||
Timer.Period = WorkerOptions.CleanSuccessfulJobsPeriod; |
|||
} |
|||
|
|||
protected override async Task DoWorkAsync(PeriodicBackgroundWorkerContext workerContext) |
|||
{ |
|||
if (!JobOptions.IsJobExecutionEnabled || |
|||
!WorkerOptions.StoreSuccessfulJobs || |
|||
WorkerOptions.SuccessfulJobRetentionTime == null) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
var store = workerContext.ServiceProvider.GetRequiredService<IBackgroundJobStore>(); |
|||
var clock = workerContext.ServiceProvider.GetRequiredService<IClock>(); |
|||
var completedBefore = clock.Now.Subtract(WorkerOptions.SuccessfulJobRetentionTime.Value); |
|||
|
|||
await using (var handle = await DistributedLock.TryAcquireAsync(WorkerOptions.CleanupDistributedLockName, cancellationToken: StoppingToken)) |
|||
{ |
|||
if (handle == null) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
int deletedCount; |
|||
do |
|||
{ |
|||
deletedCount = await store.DeleteAsync(WorkerOptions.ApplicationName, completedBefore, WorkerOptions.MaxJobFetchCount, StoppingToken); |
|||
} |
|||
while (deletedCount > 0 && deletedCount >= WorkerOptions.MaxJobFetchCount && !StoppingToken.IsCancellationRequested); |
|||
} |
|||
} |
|||
} |
|||
@ -0,0 +1,71 @@ |
|||
using System; |
|||
using System.Collections.Generic; |
|||
using System.Linq; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
/// <summary>
|
|||
/// Filters the waiting jobs of a background job worker by job name.
|
|||
/// A worker is exactly one of: no filter (<see cref="None"/>), include-only (a dedicated worker) or
|
|||
/// exclude-only (the default worker in a multi-worker setup) — the two can never be combined.
|
|||
/// </summary>
|
|||
public class BackgroundJobNameFilter |
|||
{ |
|||
/// <summary>
|
|||
/// A filter that matches every job name.
|
|||
/// </summary>
|
|||
public static BackgroundJobNameFilter None { get; } = new(BackgroundJobNameFilterMode.None); |
|||
|
|||
public BackgroundJobNameFilterMode Mode { get; } |
|||
|
|||
public IReadOnlyList<string> JobNames { get; } |
|||
|
|||
public BackgroundJobNameFilter(BackgroundJobNameFilterMode mode, IReadOnlyList<string>? jobNames = null) |
|||
{ |
|||
if (!Enum.IsDefined(typeof(BackgroundJobNameFilterMode), mode)) |
|||
{ |
|||
throw new ArgumentException($"Invalid background job name filter mode: {mode}", nameof(mode)); |
|||
} |
|||
|
|||
var names = jobNames?.Where(x => !x.IsNullOrWhiteSpace()).Distinct(StringComparer.Ordinal).ToList() ?? new List<string>(); |
|||
|
|||
if (mode == BackgroundJobNameFilterMode.None && names.Count > 0) |
|||
{ |
|||
throw new ArgumentException("Job names must be empty when the filter mode is None.", nameof(jobNames)); |
|||
} |
|||
|
|||
if (mode != BackgroundJobNameFilterMode.None && names.Count == 0) |
|||
{ |
|||
throw new ArgumentException("Job names cannot be empty when the filter mode is Include or Exclude.", nameof(jobNames)); |
|||
} |
|||
|
|||
Mode = mode; |
|||
JobNames = names.AsReadOnly(); |
|||
} |
|||
|
|||
public static BackgroundJobNameFilter Include(IReadOnlyList<string> jobNames) |
|||
{ |
|||
return new BackgroundJobNameFilter(BackgroundJobNameFilterMode.Include, jobNames); |
|||
} |
|||
|
|||
public static BackgroundJobNameFilter Exclude(IReadOnlyList<string> jobNames) |
|||
{ |
|||
return new BackgroundJobNameFilter(BackgroundJobNameFilterMode.Exclude, jobNames); |
|||
} |
|||
|
|||
/// <summary>
|
|||
/// Whether the given job name passes this filter, using an ordinal (case-sensitive) comparison for the
|
|||
/// in-memory eligibility re-check. The persistent stores translate <see cref="Mode"/> and
|
|||
/// <see cref="JobNames"/> into a database query instead, so their filtering follows the database collation.
|
|||
/// Job names are expected to be unique beyond case (they are derived from the type name by default).
|
|||
/// </summary>
|
|||
public virtual bool IsMatch(string jobName) |
|||
{ |
|||
return Mode switch |
|||
{ |
|||
BackgroundJobNameFilterMode.Include => JobNames.Contains(jobName, StringComparer.Ordinal), |
|||
BackgroundJobNameFilterMode.Exclude => !JobNames.Contains(jobName, StringComparer.Ordinal), |
|||
_ => true |
|||
}; |
|||
} |
|||
} |
|||
@ -0,0 +1,19 @@ |
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
public enum BackgroundJobNameFilterMode : byte |
|||
{ |
|||
/// <summary>
|
|||
/// No filter; all job names match.
|
|||
/// </summary>
|
|||
None = 0, |
|||
|
|||
/// <summary>
|
|||
/// Only the job names in the filter match.
|
|||
/// </summary>
|
|||
Include = 1, |
|||
|
|||
/// <summary>
|
|||
/// All job names except those in the filter match.
|
|||
/// </summary>
|
|||
Exclude = 2 |
|||
} |
|||
@ -0,0 +1,37 @@ |
|||
using System; |
|||
using System.Collections.Generic; |
|||
using System.Linq; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
/// <summary>
|
|||
/// Configuration of a dedicated <see cref="BackgroundJobWorker"/> that processes only specific job types.
|
|||
/// </summary>
|
|||
public class BackgroundJobWorkerConfiguration |
|||
{ |
|||
/// <summary>
|
|||
/// A unique distributed lock name for this worker. It must be different from the names used by other workers.
|
|||
/// It is used to serialize the worker across application instances when
|
|||
/// <see cref="AbpBackgroundJobWorkerOptions.MaxParallelJobExecutionCount"/> is 1; in parallel mode
|
|||
/// (greater than 1) jobs are claimed with per-job locks instead and this lock is not acquired.
|
|||
/// </summary>
|
|||
public string LockName { get; } |
|||
|
|||
/// <summary>
|
|||
/// The job argument types that are processed exclusively by this worker.
|
|||
/// </summary>
|
|||
public IReadOnlyList<Type> JobArgsTypes { get; } |
|||
|
|||
public BackgroundJobWorkerConfiguration(string lockName, params Type[] jobArgsTypes) |
|||
{ |
|||
LockName = Check.NotNullOrWhiteSpace(lockName, nameof(lockName)); |
|||
Check.NotNullOrEmpty(jobArgsTypes, nameof(jobArgsTypes)); |
|||
|
|||
if (jobArgsTypes.Any(t => t == null)) |
|||
{ |
|||
throw new ArgumentException("Job args types cannot contain null.", nameof(jobArgsTypes)); |
|||
} |
|||
|
|||
JobArgsTypes = jobArgsTypes.ToList(); |
|||
} |
|||
} |
|||
@ -0,0 +1,131 @@ |
|||
using System; |
|||
using System.Collections.Generic; |
|||
using System.Linq; |
|||
using System.Threading; |
|||
using System.Threading.Tasks; |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.Options; |
|||
using Volo.Abp.BackgroundWorkers; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
/// <summary>
|
|||
/// Owns and controls the background job workers.
|
|||
/// When no <see cref="AbpBackgroundJobWorkerOptions.WorkerConfigurations"/> is configured, a single
|
|||
/// default worker processes all jobs. Otherwise, one dedicated worker is started per configuration
|
|||
/// (each with its own distributed lock and job-type filter) plus a default worker for the remaining jobs.
|
|||
/// The workers are resolved from DI, so a replaced <see cref="IBackgroundJobWorker"/> is respected.
|
|||
/// </summary>
|
|||
public class BackgroundJobWorkerManager : IBackgroundWorker |
|||
{ |
|||
protected AbpBackgroundJobOptions JobOptions { get; } |
|||
|
|||
protected AbpBackgroundJobWorkerOptions WorkerOptions { get; } |
|||
|
|||
protected IServiceProvider ServiceProvider { get; } |
|||
|
|||
protected List<IBackgroundJobWorker> Workers { get; } |
|||
|
|||
public BackgroundJobWorkerManager( |
|||
IOptions<AbpBackgroundJobOptions> jobOptions, |
|||
IOptions<AbpBackgroundJobWorkerOptions> workerOptions, |
|||
IServiceProvider serviceProvider) |
|||
{ |
|||
JobOptions = jobOptions.Value; |
|||
WorkerOptions = workerOptions.Value; |
|||
ServiceProvider = serviceProvider; |
|||
Workers = new List<IBackgroundJobWorker>(); |
|||
} |
|||
|
|||
public virtual async Task StartAsync(CancellationToken cancellationToken = default) |
|||
{ |
|||
if (!JobOptions.IsJobExecutionEnabled) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
if (!WorkerOptions.WorkerConfigurations.Any()) |
|||
{ |
|||
await StartWorkerAsync(cancellationToken: cancellationToken); |
|||
return; |
|||
} |
|||
|
|||
// AddDedicatedWorker already rejects duplicate job types and lock names eagerly. This is the backstop
|
|||
// for what can only be known here: two different args types that resolve to the same job name.
|
|||
// Validate all configurations first, so a misconfiguration does not leave already-started workers running.
|
|||
var dedicatedWorkers = new List<DedicatedWorkerDefinition>(); |
|||
var allDedicatedJobNames = new List<string>(); |
|||
|
|||
// The default worker uses WorkerOptions.DistributedLockName, so dedicated workers must not reuse it.
|
|||
var lockNames = new List<string> { WorkerOptions.DistributedLockName }; |
|||
|
|||
foreach (var configuration in WorkerOptions.WorkerConfigurations) |
|||
{ |
|||
var jobNames = configuration.JobArgsTypes |
|||
.Select(GetJobName) |
|||
.Distinct() |
|||
.ToList(); |
|||
|
|||
var alreadyConfigured = jobNames.Intersect(allDedicatedJobNames).ToList(); |
|||
if (alreadyConfigured.Any()) |
|||
{ |
|||
throw new AbpException( |
|||
$"The following background job(s) are configured for more than one dedicated worker: {string.Join(", ", alreadyConfigured)}. " + |
|||
$"Each job type can be handled by only one dedicated worker."); |
|||
} |
|||
|
|||
if (lockNames.Contains(configuration.LockName)) |
|||
{ |
|||
throw new AbpException( |
|||
$"The distributed lock name '{configuration.LockName}' is used by more than one background job worker " + |
|||
$"(the default worker uses '{WorkerOptions.DistributedLockName}'). Each worker must have a unique lock name to run independently."); |
|||
} |
|||
|
|||
lockNames.Add(configuration.LockName); |
|||
allDedicatedJobNames.AddRange(jobNames); |
|||
dedicatedWorkers.Add(new DedicatedWorkerDefinition(configuration.LockName, jobNames)); |
|||
} |
|||
|
|||
foreach (var dedicatedWorker in dedicatedWorkers) |
|||
{ |
|||
await StartWorkerAsync(dedicatedWorker.LockName, BackgroundJobNameFilter.Include(dedicatedWorker.JobNames), cancellationToken); |
|||
} |
|||
|
|||
// Default worker processes every job that is not handled by a dedicated worker.
|
|||
await StartWorkerAsync(null, BackgroundJobNameFilter.Exclude(allDedicatedJobNames), cancellationToken); |
|||
} |
|||
|
|||
protected virtual string GetJobName(Type argsType) |
|||
{ |
|||
try |
|||
{ |
|||
return JobOptions.GetJob(argsType).JobName; |
|||
} |
|||
catch (AbpException ex) |
|||
{ |
|||
throw new AbpException( |
|||
$"No background job is registered for the args type '{argsType.FullName}' configured via AddDedicatedWorker. " + |
|||
$"Register the job before configuring a dedicated worker for it.", ex); |
|||
} |
|||
} |
|||
|
|||
protected virtual async Task StartWorkerAsync( |
|||
string? distributedLockName = null, |
|||
BackgroundJobNameFilter? jobNameFilter = null, |
|||
CancellationToken cancellationToken = default) |
|||
{ |
|||
var worker = ServiceProvider.GetRequiredService<IBackgroundJobWorker>(); |
|||
await worker.StartAsync(distributedLockName, jobNameFilter, cancellationToken); |
|||
Workers.Add(worker); |
|||
} |
|||
|
|||
public virtual async Task StopAsync(CancellationToken cancellationToken = default) |
|||
{ |
|||
foreach (var worker in Workers) |
|||
{ |
|||
await worker.StopAsync(cancellationToken); |
|||
} |
|||
|
|||
Workers.Clear(); |
|||
} |
|||
} |
|||
@ -0,0 +1,27 @@ |
|||
using System.Collections.Generic; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
/// <summary>
|
|||
/// A validated, ready-to-start dedicated worker: the distributed lock name it runs under and the
|
|||
/// resolved job names it is responsible for. Built by <see cref="BackgroundJobWorkerManager"/> from a
|
|||
/// <see cref="BackgroundJobWorkerConfiguration"/> after all configurations have been validated.
|
|||
/// </summary>
|
|||
public class DedicatedWorkerDefinition |
|||
{ |
|||
/// <summary>
|
|||
/// The distributed lock name this worker runs under.
|
|||
/// </summary>
|
|||
public string LockName { get; } |
|||
|
|||
/// <summary>
|
|||
/// The resolved job names this worker is responsible for.
|
|||
/// </summary>
|
|||
public IReadOnlyList<string> JobNames { get; } |
|||
|
|||
public DedicatedWorkerDefinition(string lockName, IReadOnlyList<string> jobNames) |
|||
{ |
|||
LockName = lockName; |
|||
JobNames = jobNames; |
|||
} |
|||
} |
|||
@ -1,8 +1,27 @@ |
|||
using Volo.Abp.BackgroundWorkers; |
|||
using System.Collections.Generic; |
|||
using System.Threading; |
|||
using System.Threading.Tasks; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
public interface IBackgroundJobWorker : IBackgroundWorker |
|||
/// <summary>
|
|||
/// A background job worker that polls and executes waiting jobs.
|
|||
/// Instances are created, configured and started by <see cref="BackgroundJobWorkerManager"/>.
|
|||
/// </summary>
|
|||
public interface IBackgroundJobWorker |
|||
{ |
|||
/// <summary>
|
|||
/// Starts this worker.
|
|||
/// </summary>
|
|||
/// <param name="distributedLockName">
|
|||
/// Distributed lock name for this worker. When null, <see cref="AbpBackgroundJobWorkerOptions.DistributedLockName"/> is used.
|
|||
/// </param>
|
|||
/// <param name="jobNameFilter">Filters the jobs this worker processes by name. When null, all jobs are processed.</param>
|
|||
/// <param name="cancellationToken">Cancellation token.</param>
|
|||
Task StartAsync( |
|||
string? distributedLockName = null, |
|||
BackgroundJobNameFilter? jobNameFilter = null, |
|||
CancellationToken cancellationToken = default); |
|||
|
|||
Task StopAsync(CancellationToken cancellationToken = default); |
|||
} |
|||
|
|||
@ -0,0 +1,32 @@ |
|||
using Microsoft.AspNetCore.Http; |
|||
using Microsoft.Extensions.Options; |
|||
using Shouldly; |
|||
using Xunit; |
|||
|
|||
namespace Volo.Abp.AspNetCore.Uow; |
|||
|
|||
public class AspNetCoreUnitOfWorkTransactionBehaviourProvider_Tests |
|||
{ |
|||
private static AspNetCoreUnitOfWorkTransactionBehaviourProvider CreateProvider(string method) |
|||
{ |
|||
var httpContext = new DefaultHttpContext(); |
|||
httpContext.Request.Method = method; |
|||
|
|||
return new AspNetCoreUnitOfWorkTransactionBehaviourProvider( |
|||
new HttpContextAccessor { HttpContext = httpContext }, |
|||
Microsoft.Extensions.Options.Options.Create(new AspNetCoreUnitOfWorkTransactionBehaviourProviderOptions())); |
|||
} |
|||
|
|||
[Theory] |
|||
[InlineData("GET", false)] |
|||
[InlineData("QUERY", false)] |
|||
[InlineData("query", false)] |
|||
[InlineData("HEAD", true)] |
|||
[InlineData("POST", true)] |
|||
[InlineData("PUT", true)] |
|||
[InlineData("DELETE", true)] |
|||
public void IsTransactional_Should_Treat_Get_And_Query_As_Non_Transactional(string method, bool expected) |
|||
{ |
|||
CreateProvider(method).IsTransactional.ShouldBe(expected); |
|||
} |
|||
} |
|||
@ -0,0 +1,64 @@ |
|||
using System; |
|||
using System.Threading.Tasks; |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.DependencyInjection.Extensions; |
|||
using NSubstitute; |
|||
using Xunit; |
|||
|
|||
namespace Volo.Abp.Auditing; |
|||
|
|||
public class AuditingInterceptor_HttpMethod_Tests : AbpAuditingTestBase |
|||
{ |
|||
protected IAuditingStore AuditingStore; |
|||
|
|||
private string? _httpMethod; |
|||
|
|||
protected override void AfterAddApplication(IServiceCollection services) |
|||
{ |
|||
AuditingStore = Substitute.For<IAuditingStore>(); |
|||
services.Replace(ServiceDescriptor.Singleton(AuditingStore)); |
|||
|
|||
services.Configure<AbpAuditingOptions>(options => |
|||
{ |
|||
options.IsEnabledForGetRequests = false; |
|||
options.Contributors.Add(new TestHttpMethodAuditContributor(() => _httpMethod)); |
|||
}); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Not_Write_AuditLog_For_Query_Http_Method_Without_Explicit_Scope() |
|||
{ |
|||
_httpMethod = "QUERY"; |
|||
|
|||
var auditedObject = GetRequiredService<Auditing_Tests.MyAuditedObject1>(); |
|||
await auditedObject.DoItAsync(new Auditing_Tests.InputObject { Value1 = "x", Value2 = 1 }); |
|||
|
|||
await AuditingStore.DidNotReceive().SaveAsync(Arg.Any<AuditLogInfo>()); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Write_AuditLog_For_Post_Http_Method_Without_Explicit_Scope() |
|||
{ |
|||
_httpMethod = "POST"; |
|||
|
|||
var auditedObject = GetRequiredService<Auditing_Tests.MyAuditedObject1>(); |
|||
await auditedObject.DoItAsync(new Auditing_Tests.InputObject { Value1 = "x", Value2 = 1 }); |
|||
|
|||
await AuditingStore.Received().SaveAsync(Arg.Any<AuditLogInfo>()); |
|||
} |
|||
|
|||
public class TestHttpMethodAuditContributor : AuditLogContributor |
|||
{ |
|||
private readonly Func<string?> _httpMethodFactory; |
|||
|
|||
public TestHttpMethodAuditContributor(Func<string?> httpMethodFactory) |
|||
{ |
|||
_httpMethodFactory = httpMethodFactory; |
|||
} |
|||
|
|||
public override void PreContribute(AuditLogContributionContext context) |
|||
{ |
|||
context.AuditInfo.HttpMethod = _httpMethodFactory(); |
|||
} |
|||
} |
|||
} |
|||
@ -0,0 +1,27 @@ |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.DependencyInjection.Extensions; |
|||
using Volo.Abp.Autofac; |
|||
using Volo.Abp.Modularity; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
[DependsOn( |
|||
typeof(AbpBackgroundJobsModule), |
|||
typeof(AbpAutofacModule), |
|||
typeof(AbpTestBaseModule) |
|||
)] |
|||
public class AbpAutoLockNameWorkerTestModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
context.Services.AddSingleton<WorkerStartRecorder>(); |
|||
context.Services.Replace(ServiceDescriptor.Transient<IBackgroundJobWorker, RecordingBackgroundJobWorker>()); |
|||
|
|||
// No lock name is given: it is derived from the job argument type names.
|
|||
Configure<AbpBackgroundJobWorkerOptions>(options => |
|||
{ |
|||
options.AddDedicatedWorker<WorkerJobAArgs>(); |
|||
options.AddDedicatedWorker<WorkerJobBArgs>(); |
|||
}); |
|||
} |
|||
} |
|||
@ -0,0 +1,23 @@ |
|||
using System; |
|||
using Volo.Abp.Autofac; |
|||
using Volo.Abp.Modularity; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
[DependsOn( |
|||
typeof(AbpBackgroundJobsModule), |
|||
typeof(AbpAutofacModule), |
|||
typeof(AbpTestBaseModule) |
|||
)] |
|||
public class AbpBackgroundJobCleanupTestModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
// IsJobExecutionEnabled is true by default, which the cleanup worker requires.
|
|||
Configure<AbpBackgroundJobWorkerOptions>(options => |
|||
{ |
|||
options.StoreSuccessfulJobs = true; |
|||
options.SuccessfulJobRetentionTime = TimeSpan.FromDays(1); |
|||
}); |
|||
} |
|||
} |
|||
@ -0,0 +1,25 @@ |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Volo.Abp.Autofac; |
|||
using Volo.Abp.Modularity; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
[DependsOn( |
|||
typeof(AbpBackgroundJobsModule), |
|||
typeof(AbpAutofacModule), |
|||
typeof(AbpTestBaseModule) |
|||
)] |
|||
public class AbpBackgroundJobWorkerTestModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
// Drive the worker manually in tests; don't run the real periodic worker.
|
|||
Configure<AbpBackgroundJobOptions>(options => |
|||
{ |
|||
options.IsJobExecutionEnabled = false; |
|||
}); |
|||
|
|||
context.Services.AddSingleton<ParallelJobTracker>(); |
|||
context.Services.AddScoped<ScopeMarker>(); |
|||
} |
|||
} |
|||
@ -0,0 +1,27 @@ |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.DependencyInjection.Extensions; |
|||
using Volo.Abp.Autofac; |
|||
using Volo.Abp.Modularity; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
[DependsOn( |
|||
typeof(AbpBackgroundJobsModule), |
|||
typeof(AbpAutofacModule), |
|||
typeof(AbpTestBaseModule) |
|||
)] |
|||
public class AbpDuplicateLockNameTestModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
context.Services.AddSingleton<WorkerStartRecorder>(); |
|||
context.Services.Replace(ServiceDescriptor.Transient<IBackgroundJobWorker, RecordingBackgroundJobWorker>()); |
|||
|
|||
// Two workers with different job types but the same lock name, which must fail at initialization.
|
|||
Configure<AbpBackgroundJobWorkerOptions>(options => |
|||
{ |
|||
options.AddDedicatedWorker<WorkerJobAArgs>("dup-lock"); |
|||
options.AddDedicatedWorker<WorkerJobBArgs>("dup-lock"); |
|||
}); |
|||
} |
|||
} |
|||
@ -0,0 +1,27 @@ |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.DependencyInjection.Extensions; |
|||
using Volo.Abp.Autofac; |
|||
using Volo.Abp.Modularity; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
[DependsOn( |
|||
typeof(AbpBackgroundJobsModule), |
|||
typeof(AbpAutofacModule), |
|||
typeof(AbpTestBaseModule) |
|||
)] |
|||
public class AbpDuplicateWorkerTestModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
context.Services.AddSingleton<WorkerStartRecorder>(); |
|||
context.Services.Replace(ServiceDescriptor.Transient<IBackgroundJobWorker, RecordingBackgroundJobWorker>()); |
|||
|
|||
// The same job type is assigned to two dedicated workers, which must fail at initialization.
|
|||
Configure<AbpBackgroundJobWorkerOptions>(options => |
|||
{ |
|||
options.AddDedicatedWorker<WorkerJobAArgs>("lock-a"); |
|||
options.AddDedicatedWorker<WorkerJobAArgs>("lock-b"); |
|||
}); |
|||
} |
|||
} |
|||
@ -0,0 +1,28 @@ |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.DependencyInjection.Extensions; |
|||
using Volo.Abp.Autofac; |
|||
using Volo.Abp.Modularity; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
[DependsOn( |
|||
typeof(AbpBackgroundJobsModule), |
|||
typeof(AbpAutofacModule), |
|||
typeof(AbpTestBaseModule) |
|||
)] |
|||
public class AbpMultiWorkerTestModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
context.Services.AddSingleton<WorkerStartRecorder>(); |
|||
|
|||
// Replace the real worker with a recording one to assert how the manager resolves and starts workers.
|
|||
context.Services.Replace(ServiceDescriptor.Transient<IBackgroundJobWorker, RecordingBackgroundJobWorker>()); |
|||
|
|||
Configure<AbpBackgroundJobWorkerOptions>(options => |
|||
{ |
|||
options.AddDedicatedWorker<WorkerJobAArgs>("lock-a"); |
|||
options.AddDedicatedWorker<WorkerJobBArgs>("lock-b"); |
|||
}); |
|||
} |
|||
} |
|||
@ -0,0 +1,29 @@ |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Microsoft.Extensions.DependencyInjection.Extensions; |
|||
using Volo.Abp.Autofac; |
|||
using Volo.Abp.Modularity; |
|||
|
|||
namespace Volo.Abp.BackgroundJobs; |
|||
|
|||
[DependsOn( |
|||
typeof(AbpBackgroundJobsModule), |
|||
typeof(AbpAutofacModule), |
|||
typeof(AbpTestBaseModule) |
|||
)] |
|||
public class AbpSameJobNameTestModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
context.Services.AddSingleton<WorkerStartRecorder>(); |
|||
context.Services.Replace(ServiceDescriptor.Transient<IBackgroundJobWorker, RecordingBackgroundJobWorker>()); |
|||
|
|||
// Two dedicated workers with different args types that both resolve to "shared-job-name".
|
|||
// AddDedicatedWorker's eager check compares by type (both pass); only the manager's backstop
|
|||
// (which resolves job names) can catch this.
|
|||
Configure<AbpBackgroundJobWorkerOptions>(options => |
|||
{ |
|||
options.AddDedicatedWorker<SharedNameJobAArgs>("lock-a"); |
|||
options.AddDedicatedWorker<SharedNameJobBArgs>("lock-b"); |
|||
}); |
|||
} |
|||
} |
|||