Changes needed for 7.00.177.00 compatibility

[SBarnes]

Thanks Mike,

I agree the Razor stuff would be beyond the scope of a traditional web api, although it would introduce the idea of being able to deploy a web store as a plugin to Jiwa if the extra files could be stored into the database which would be the ideal but obviously you have your hands full getting the main parts working first.

By the way we now have two candidates/customers (one which we have discussed before) and possibly a third who are very interested in the web api for us to develop them a web store from, is there any update on the timeline for the next development release?

[Mike.Sheen]

is there any update on the timeline for the next development release?

All I can say is "Real Soon (TM)"

We've been fortunate the last few weeks to be given the time to really focus on it, but last week I was diverted to other projects - Scott's still working on it, so it hasn't stopped, just slowed down. We plan on doing a new development build once we've finished writing all the DTO's, services and tests for everything we think an ecommerce application would need (Inventory, Debtors, Sales). I think we're about 90% the way through that, so a few more days yet.

Our plan was to also fix all the outstanding issues slotted in for the next release (around 39 issues currently) - we typically can knock off anywhere between 10 and 20 issues a day - so add on a few days for that and we're looking at least a week from now.

We've still not tested SSL, that should be simply a server configuration issue - but we will have to test that and document how to setup SSL for IIS, Self hosted and Azure App services.

We also found an issue or two with the ServiceStack implementation of the OpenAPI spec - we've reported those and they've been fixed by the ServiceStack team - Those will be in the next ServiceStack release (4.5.9) - but we probably won't wait for that if we're ready to do a development build before then.

We also have an issue when sending request headers for compression (seems to be always returning a 200 response, as the response is compressed with any error information EDIT: Fixed in ServiceStack 4.5.9) - that also probably won't stop us from doing a development build - but it's something we certainly need to look at for the public release.

We've also got a new developer joining our team in a couple of weeks - so we will be able to increase our release cadence into the future.

[SBarnes]

Hi Mike,

Thanks for the update, I'll mark real soon in my calendar.

Sounds like some of the dead lines I like to commit to on projects.

Speaking of azure app services have you done much testing / deployment with the API in this area, it one of the areas I was looking at possibly using it in, even possibly mobile wise as well as web wise?

[Mike.Sheen]

Speaking of azure app services have you done much testing / deployment with the API in this area, it one of the areas I was looking at possibly using it in, even possibly mobile wise as well as web wise?

Yes - the demo of our REST API, http://api.jiwa.com.au is deployed as an Azure App Service - has been for a number of months now. It was pretty seamless for us - Visual Studio has an option to deploy to Azure and that's what we currently use to deploy - but we'll be providing guidance on how to deploy the REST API to Azure as an App Service, as others won't have the VS project to deploy from Visual Studio.

[SBarnes]

Thanks Mike,

By this I would assume you have the API running as an API app or possibly a web app but how are things configured in terms of where Jiwa itself and where the database is sitting as I would assume you have everything sitting in Azure and not some sort of hybrid solution?

I am trying to get some idea of how configurable a solution in terms of cloud and on premise may be at the end of the day.

[Mike.Sheen]

By this I would assume you have the API running as an API app or possibly a web app but how are things configured in terms of where Jiwa itself and where the database is sitting as I would assume you have everything sitting in Azure and not some sort of hybrid solution?

It's what they call an App Service which is really just an IIS site - It's a low cost option (or free, even - if you don't mind using an azurewebsites.* domain name). We use the Shared pricing tier ($15 per month) which lets us use a custom domain (api.jiwa.com.au) - soon we'll need to bump that another tier when we deploy with SSL - the costs and features of each pricing tier are outlined on the Azure pricing page.

Our SQL database is also in Azure, but it does not need to be - however latency between the app service and the SQL server should be kept down, so it makes sense to have a SQL database in Azure also. When I say the SQL database is in Azure, I mean it's an Azure SQL Server, not a VM running SQL Server - so it's true database-as-a-service, which has lots of nice features like automatic backups every few minutes and automatic replication across 3 fault zones with automatic failover, and the option of georedundancy (replicating to another Azure DC in real-time, and again with automatic failover).

There's nothing stopping you pointing the Azure app service to an on-premise SQL server, or one in another cloud such as AWS - the configuration file just needs to know the DNS or IP address of the SQL server to reach it - but I reiterate my earlier point about latency - you're going to be talking tens of milliseconds for each database query when not in the same physical location compared to sub-millisecond responses when they are in the same physical location.

We provide all the assemblies the App service needs to run - it contains the Jiwa assemblies (as well as all other related assemblies, such as ServiceStack) - they get deployed to the App Service and it all magically works. The only thing you need to do is edit the config file to provide the SQL Server address, the database name and the Jiwa credentials to use on initial startup - and you can edit that file by adding your own set of FTP credentials to the Azure App Service, downloading the App.config file with an FTP client, editing it and uploading it back up to the Azure App Service.

The 3 options we provide for hosting the REST API are:

• Self hosted (windows service) (on-premise, VPS, hosted dedicated server, VM)
• IIS Site (on-premise, VPS, hosted dedicated server, VM)
• Azure App Service

Where you put the Self hosted or IIS is up to you - but with latency in mind the options will narrow down quickly based on the location of the SQL Server.

Hope that helps!

[SBarnes]

Hi Mike,

Are we at this stage any closer to knowing an approximate next development release date, I am also getting a bit of pressure on the transaction splitting for order processing that will be in the same release?

Thanks

[Mike.Sheen]

Hi Mike,

Are we at this stage any closer to knowing an approximate next development release date, I am also getting a bit of pressure on the transaction splitting for order processing that will be in the same release?

Thanks

A few weeks from now, at best, I'm afraid.

Here's a chart highlighting the challenges we face in sticking to schedule.

Management 101

You can see the above chart at any time here to track progress.

[SBarnes]

Hi Mike,

Thanks for the update, are there dramatic differences between 7.180 and 7.181 in terms of the API?

What I am trying to work out is, is it worthwhile trying to get something started against 180, or would it largely have to be scrapped when 181 is released, I do realise I could be asking about the length of a piece of string?

Thanks

[Mike.Sheen]

Hi Mike,

Thanks for the update, are there dramatic differences between 7.180 and 7.181 in terms of the API?

What I am trying to work out is, is it worthwhile trying to get something started against 180, or would it largely have to be scrapped when 181 is released, I do realise I could be asking about the length of a piece of string?

Thanks

I think there's enough changes between the two to be a bit annoying.

To give you an idea of what's changed, compare the GET request for an inventory item in 7.00.180.00

Code: Select all

[Authenticate]
public JiwaServiceModel.Inventory.InventoryItem Get(InventoryGetRequest request)
{      
   JiwaApplication.Manager manager = null;
   if (! JiwaFinancials.Jiwa.JiwaApplication.Manager.ManagerUsedPool.TryGetValue(this.GetSessionId(), out manager))               
      throw new UnauthorizedAccessException(); // There was no manager instance associated with the sessionID
   
   JiwaFinancials.Jiwa.JiwaInventory.Inventory inv = manager.BusinessLogicFactory.CreateBusinessLogic<JiwaFinancials.Jiwa.JiwaInventory.Inventory>(null);
   inv.Read(request.InventoryID);

   return inv.DTO_Serialise();
}


And in 7.00.181.00:

Code: Select all

[Authenticate]
[Compression]
public JiwaFinancials.Jiwa.JiwaServiceModel.Inventory.InventoryItem Get(InventoryGETRequest request)
{                        
   JiwaApplication.Manager manager = Helper.Service.GetManager(this);                                                                   
   JiwaFinancials.Jiwa.JiwaInventory.Inventory Inventory = Helper.Service.GetMaintenanceBusinessLogic<JiwaFinancials.Jiwa.JiwaInventory.Inventory>(manager, this, request.InventoryID,
      (i, m, s) =>
      {
         i.Read(request.InventoryID);
         if (Helper.Service.IsStateful(s))
         {
            m.ObjectDictionary.Add(i.InventoryID, i);
         }
      } );
      
   return Inventory.DTO_Serialise();
}


We introduced a static Helper class to shield us from repetitive tasks, such as creating a business logic class - like the GetMaintenanceBusinessLogic method.

This accepts as an optional parameter an anonymous method to be executed after the business logic is created. The anonymous method in the above example also is aware of a new request header "jiwa-stateful" which allows requests to be stateful - it will tell the server to hold an instance of the business logic in memory within the session, so subsequent PATCH or GET's all retrieve the in-memory instance - so we can have consumers of the API behave in a similar fashion to the desktop application and nothing is committed until instructed to save or cancel changes (in the API we have a SAVE or ABANDON request to instruct a save or cancel of an edit).

The stateful aspect may not affect you if you're building something to import / upload or just query - but if it's an interactive application the stateful feature would be of use.

Mike

EDIT: I just realised by looking at that GET from 7.00.181.00 it might not be entirely obvious how the stateful aspect works - it would appear to never retrieve an in-memory object and always add one - so below is the code for the GetMaintenanceBusinessLogic method which may make things clearer - it shows if a stateful request is provided and an ObjectDictionaryKey (in this case an InventoryID), it retrieves that business logic from the ObjectDictionary, otherwise it then creates it and executes the anonymous method PostFactoryCreateAction - and that adds it to the ObjectDictionary.

Code: Select all

public static T GetMaintenanceBusinessLogic<T>(JiwaApplication.Manager Manager, ServiceStack.Service Service, string ObjectDictionaryKey, Action<T, JiwaApplication.Manager, ServiceStack.Service> PostFactoryCreateAction) where T:JiwaFinancials.Jiwa.JiwaApplication.BusinessLogic.Maintenance, new()
{
   T businessLogic = null;
   if (IsStateful(Service) && ObjectDictionaryKey != null)
   {
      object objectDictionaryValue = null;
      if (! Manager.ObjectDictionary.TryGetValue(ObjectDictionaryKey, out objectDictionaryValue))            
      {
         businessLogic = Manager.BusinessLogicFactory.CreateBusinessLogic<T>(null);   
         if (PostFactoryCreateAction != null)
            PostFactoryCreateAction(businessLogic, Manager, Service);
      }
      else
         businessLogic = (T)objectDictionaryValue;
   }
   else
   {
      businessLogic = Manager.BusinessLogicFactory.CreateBusinessLogic<T>(null);
      
      if (PostFactoryCreateAction != null)
         PostFactoryCreateAction(businessLogic, Manager, Service);
   }
   
   return businessLogic;
}