Base solution for your next web application
Starts in:
01 DAYS
01 HRS
01 MIN
01 SEC

Activities of "BobIngham"

.NET Core, Angular, ASPNET Framework 4.6.0, Zero 6.8.0 I want to implement my own StripePaymentAppService. My conventions are to leave alone the Zero implementation, copy the code and then implement my own. Create new service: NuagecareStripePaymentAppService, copied from StripePaymentAppService and modified: Create new interface, INuagecareStripePaymentAppService, copied direct from IStripePaymentAppService Then, in [ProjectName].Application.[ProjectName]ApplicationModule inject the new service using the following code:

//Replace StripePaymentAppService with NuagecareStripePaymentAppService
Configuration.ReplaceService(typeof(IStripePaymentAppService), () =>
{
    Configuration.IocManager.IocContainer.Register(
        Component.For<IStripePaymentAppService, INuagecareStripePaymentAppService>()
                    .ImplementedBy<NuagecareStripePaymentAppService>()
                    .LifestyleTransient()
    );
});

However, I get an error in Visual Studio: What am I doing worong and what's best practise here?

Hi @ismcagdas, yep I have no problem in continuing over there. Makes sense to close the issue and keep the forum tidy.

Hi @ajayak, If you're happy working with Hangfire then stick with Hangfire only. Invoke Hangfire in your WebCoreModule as above. Place your job in the HangfireService:

public class HangfireService
{
    public static void InitializeJobs()
    {
        RecurringJob.AddOrUpdate<ShipmentAddressLocationCoordinatesWorker>(job => job.Execute(0), "50 1 * * 0");
        return;
    }
}

Then your worker looks something like below. You are trying to run an abp background worker by firing it from Hangfire.

namespace Nuagecare.Web.Hangfire.Workers
{
    public class UpdateFromDataProvider : BackgroundJob<int>, ITransientDependency
    {
        public IAbpSession _abpSession;
        private readonly IRepository<Tenant> _tenantRepository;
        private readonly DataProviderAPIProvider _dataProviderAPIProvider;


        public UpdateFromDataProvider(
            IAbpSession abpSession,
            IRepository<Tenant> tenantRepository,
            DataProviderAPIProvider dataProviderAPIProvider)
        {
            _abpSession = abpSession;
            _tenantRepository = tenantRepository;
            _dataProviderAPIProvider = dataProviderAPIProvider;
        }

        [DisableConcurrentExecution(timeoutInSeconds: 10 * 60)]
        [AutomaticRetry(Attempts = 0)]
        public override void Execute(int number)
        {
            var env = AppDomain.CurrentDomain.GetData("HostingEnvironment") as IHostingEnvironment;
            ... code removed for brevity

Hopefully that shuold be a little clearer. Here's how it looks in VS. Probably the guys at Zero will tell me I have everything wrong!!!! This has been up and working in an Azure production site for over a year and never fails.

@ajayak When you use Hangfire it's initialised in your Startup and instantiated in your WebCoreModule, which you probably already know:

if (WebConsts.HangfireDashboardEnabled)
{
    //Hangfire(Enable to use Hangfire instead of default job manager)
    services.AddHangfire(config =>
    {
        config.UseSqlServerStorage(_appConfiguration.GetConnectionString("Default"));
        HangfireService.InitializeJobs();
    });
}

Your HangfireService class triggers jobs using standard CRON scheduling:

public class HangfireService
{
    public static void InitializeJobs()
    {
        RecurringJob.AddOrUpdate<UpdateFromDataProvider>(job => job.Execute(0), "30 * * * *");
        return;
    }
}

Zero's background jobs work a little differently. They are instantiated into your WebHostModule:

if (IocManager.Resolve<IMultiTenancyConfig>().IsEnabled)
{
    var workManager = IocManager.Resolve<IBackgroundWorkerManager>();
    workManager.Add(IocManager.Resolve<SubscriptionExpirationCheckWorker>());
    workManager.Add(IocManager.Resolve<SubscriptionExpireEmailNotifierWorker>());
}

And the timing is declared at the top of the Worker class:

namespace Nuagecare.MultiTenancy
{
    public class SubscriptionExpirationCheckWorker : PeriodicBackgroundWorkerBase, ISingletonDependency
    {
        private const int CheckPeriodAsMilliseconds = 1 * 60 * 60 * 1000; //1 hour

Hope that helps. Zero's background workers and Hangfire workers can work, it's not one or the other, it can be both.

Question

This one's for @ismcagdas. You mentioned Metronic 7 is due. Do you have any timescales for this before I pour resource in getting to 8.2? Also, they now have 30 demos with "more coming soon", is @hilkakan going to demand that all of these demos are included in the new version ;-)

Hi @demirmusa, now I understand - I have always used Hangfire for my background jobs so took me a little while to figure out how the Zero implementation works. Now I can see it, thanks to your help.

Thanks, @maliming. I will carry out the necessary changes in the AppSettingsProvider.

In my SettingsProvider I want to be able to set a default value from a variable, tenancyName:

new SettingDefinition(
    name: NuageSettings.NuageTenantManagement.DocumentationContainer,
    defaultValue: GetTenantName(),
    scopes: SettingScopes.Tenant,
    displayName: null,
    description: null,
    group: null,
    isVisibleToClients: true,
    isInherited: true,
    customData: null),

Now, I have tried implementing a private method at the foot of the SettingsProvider called GetTenantName() but there is actually no way to return the tenancy name using the TenantManager synchronously. SettingDefinitions are returned using a synchronous method:

public override IEnumerable<SettingDefinition> GetSettingDefinitions(SettingDefinitionProviderContext context)

So how do I get the tenancy name and apply it as a default in my settings? The Use Case is that I have a document library held in Blob Storage, each tenant has a new library copied from a default library when the tenant is created. Some tenants may want to use a different or common library so it essential that they can change the setting.

You can for me, I'm sure @mitch has sorted his problem so won't mind this being closed.

Thanks @maliming. I don't want to add another nuget package for the sake of declaring a [HttpGet] atttribute. This is down to naming conventions, by renaming the Restore method to GetRestore I was able to circumvent the problem. Hardly ideal, but hey-ho! Thanks for your help in the meantime, you pointed me in thye right direction.

Showing 121 to 130 of 619 entries