Jiwa

The scheduler has a PluginsToExclude section you can populate in the config; is there something similar for the REST API service?

I have a number of "UI-only" plugins that I really don't need the API wasting its time compiling and loading.

pricerc wrote:The scheduler has a PluginsToExclude section you can populate in the config; is there something similar for the REST API service?

I have a number of "UI-only" plugins that I really don't need the API wasting its time compiling and loading.

No we do not have that there. I know we have such settings for the PluginScheduler Service - PluginsToExclude and PluginsToInclude - but that doesn't do what you probably think it does - plugins excluded are still compiled and loaded by the service at login time - we just don't call their ScheduledExecutionPlugin class interface methods Execute and Setup - but they still get compiled and loaded at login.

Do you have a concern around performance? If so, what response times are you seeing and what would you deem to be an acceptable repsonse time?

EDIT: If you could share the output of /Queries/StartupLog, that's a good first step at measuring the time plugins are taking - the below is from our demo api

https://api.jiwa.com.au/Queries/Startup ... AsRJznB_Ok

I should add that if we did exclude plugins from compilation and load selectively, you'd need to be VERY careful about what you did or did not have in those plugins.

Things like custom fields and system settings might be defined in a plugin you wish to exclude, so you'd then to make sure you separate plugins so things like custom fields and system settings and business logic are not excluded.

The original design philosophy behind plugins was that a plugin encompassed "all the bits" of a discrete customisation - form changes, business logic rules, system settings and custom fields - so to deploy that "feature" was a single plugin import, and to disable it was a single plugin disable or delete. Splitting that across multiple plugins muddies that a bit (although your plugins themselves could detect a plugin delete / disable and perform the logic to disable or delete related plugins I suppose...)

I've been doing some experimenting on my development VM.

I have a UI-only plugin (Stripe) that has a startup check that throws an exception if it fails - with a UI active, it triggers a messagebox.

For the API, it causes some other weirdness that I can't remember now that I've spent the last 6 hours on something completely different (customers and their problems...)

For my current purposes, I have changed the error-handling to ignore. Which seems to work so far.

But that may have all been a red herring.

My API is currently using 'Admin' (because it's a dev VM) and I decided to experiment and so created a new user called "API". And a new service account to run it under. The service account seems to be working ok, but if I use my new Jiwa user, I get weird errors. like the one below, which works fine when I started the API using Admin (in either case using my new Windows "service" account).

From POSTMAN when testing (with some abbreviating for clarity).

Code: Select all

{
   "ResponseStatus": {
      "ErrorCode": "InvalidOperationException",
      "Message": "ExecuteReader: Connection property has not been initialized.",
      "StackTrace": "[SalesQuoteMAKEORDERRequest: 28/10/2022 02:42:25]:
[REQUEST: {QuoteID:c5c39382e410413b815b}]
System.InvalidOperationException: ExecuteReader: Connection property has not been initialized.
   at System...SqlCommand.ValidateCommand(String method, Boolean async)
   at System...SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)
   at System...SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
   at System...SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
   at System...SqlCommand.ExecuteReader(CommandBehavior behavior)
   at Jiwa...JiwaODBC.database.ExecuteReader(SqlCommand SQLCommand, CommandBehavior CommandBehaviour)
   at Jiwa...JiwaODBC.database.ExecuteReader(SqlCommand SQLCommand)
   at Jiwa...JiwaInventory.Classification.ReadDefaultRecord()
   at Jiwa...JiwaInventory.Inventory.Setup()
   at Jiwa...JiwaApplication.BusinessLogicFactory.CreateBusinessLogic[BusinessLogicType](IJiwaForm Client)
   at AERP...AerpInventoryLibrary.GetInventoryFromID(String InventoryID) in :line 58
   at AERP...AerpInventoryLibrary.GetCategory1ExpiryDateFromInventoryID(String InventoryID) in :line 68
   at AERP...BusinessLogicPlugin.SalesOrderLines_AddInventoryItemEnd(SalesOrderLine Item) in :line 961
   at Jiwa...SalesOrderLineCollection.AddInventoryItem(String InventorySeed, SalesOrderLineInventorySeedTypes InventorySeedType, Object& NewKey, SalesOrderLine KitHeader, Int32 LineNumber)
   at Jiwa...SalesOrder.CreateNew(NewSalesOrderTypes NewSalesOrderType, String DebtorSeed, Boolean DebtorSeedIsID, String InvoiceHistoryID, String JobID, String QuoteHistoryID, String LogicalWarehouseID)
   at Jiwa...SalesQuote.MakeOrder(SalesOrderTypes eOrderType)
   at Jiwa...JiwaServiceModel.SalesQuoteServices.Post(SalesQuoteMAKEORDERRequest request) in :line 21169
   at lambda_method(Closure , Object , Object )
   at ServiceStack.Host.ServiceRunner`1.<ExecuteAsync>d__13.MoveNext()",
      "Errors": []
   }
}


If I change the API service to log on as Admin instead of API, then this works.

I will get back to this next week some time, it is mostly a learning exercise for me, so it is not urgent.

Is your api user in the admin group?

SBarnes wrote:Is your api user in the admin group?

yes

Are both set to the same Jiwa users for the database?