Starting with version 3.9, autumn 2017, we will be removing the web service method SavePermanentProductAndTerm it has been replace by the ChangeSubscriptionProductPermanently which does the same thing but is also more general purpose in that you don’t need to change the term or the number of copies, but you have to option to do so.
The same service, i.e. the SubscriptionChangeService can be used for other permanent manipulations of a subscription, and moving forward this is where you will find new methods for manipulating a subscription.
It is time for another round of removing deprecated/legacy web service methods from the API.
This time around we are going to primarily remove methods related to creating customers and subscriptions, as well as removing the legacy creditcard/payment API.
Deprecating Subscription Creation
We have a long list of methods that have popped up over the years for creating new subscribers with various parameters, all of which was finally replaced with a common shared routine as described on the documentation site.
The methods that will be removed from version 3.8 in the spring of 2017 are as follows:
All of the above methods can be replaced by the careful use of the OrderSubscription method.
Payment API Version1
Our first, and rather failed, attempt at creating a credit card payment API has not been actively supported in years, and hopefully no one is using any parts of it any longer. Thus without further ado, we will remove an entire endpoint and two support methods from the InfoWebXmlWebservice endpoint by version 3.8.
The entire credit card API has been replaced so there are no direct alternatives, but head over to the section on credit card payments to get some info on implementing credit card payments using the new api.
Various Legacy methods with better alternatives
Additionally we got some methods which have had better alternatives for quite a while, but does not fall into a specific category. As far as we can tell from our statistics they are still in use to some degree, but they should really be replaced!
This post is not about features of the application or new shiny things, but rather a description of what we are doing internally to provide you with better/more robust software.
The term “better” is of course subjective, but at least then software with fewer errors in it!
Errors in the wild
As mentioned a few times earlier we track errors as they occur in the wild, and we have been doing that for some time now (roughly two years). Doing that has allowed us to give you users better error messages and better overall error handling as well as avoiding a heap of errors. Analysing the session results over time we have observed that the number of sessions with unhandled/unexplained error messages have decreased, but still up to 20% of all session experience some sort of error.
We have taken care of all the low hanging fruit, the error messages that happen now are often rather cryptic and even though they point to a place in the application where the error was triggered, there is no easy way to tell what actually caused the error. For instance most, if not all, of our users have seen errors messages such as “The Data Has Changed Since You Read Them, Please Try Again” or “Failed to enable constraints. One or more rows contain values violating non-null, unique, or foreign-key constraints”. The first message might actually be legit, but in most cases it is not, rather it is an unfortunate sequence of read, update, insert and delete actions that causes the storage layer of the application to be confused. The latter is always a case of the application not handling its own data relationships in the proper way. Now both of these might sound easy to fix, but sometimes the sequences that precedes such an error is so “weird” or long that we are unable to reproduce it, and when the error is reported the users can’t remember the steps either.
In an attempt to figure out what these errors are, we decided to set down a task force which job it is to continuously monitor errors as they come in, and try to reproduce it immediately. This also means taking contact with the customer/person who experienced the error and have him/her explain (if possible) what was done to provoke the error.
Currently we are focusing on errors from the latest 184.108.40.206 release and ignoring everything else, so anything from beta releases or older releases will not be examined by the task force (feel free to report them anyway).
We hope that this initiative will take care of some of the more difficult and annoying problems that you as users experience.
Analysing Source Code
Another related initiative in the developer group is the use of a new static code analysis suite. The use of static code analysis is nothing new, but often static code analysis tools focus on a very broad set of best coding practices for a given language. The tool we have deployed takes another approach and only focuses on things that will result in actual errors when running the application. It helps us to avoid writing code with hard to find errors such as resource/memory leaks and threading issues. Of course it also helps with less hard to find issues such as null reference problems.
For the foreseeable future the goal is to not add more errors, once we get comfortable with the tooling, we will start investigating the backlog to remove possible errors already present in the code base.
There is a backlog, but having spent a large part of the last 3 years changing the internal procedures and hunting specific error types we are already a long way, and the amount of so called “High Impact” issues (i.e. bad errors) is actually rather small (both in relative and absolute terms).
Hopefully both of these initiatives will provide you with “better” software over the following releases. We do still need your help however, so continue to submit issues to support as you find them.
As you might have noticed INFO-Web, the old self-service web client, is being discontinued. There is a “modern” replacement called INFO-Cweb which everyone with an INFO-Web license should have received an upgrade offer for.
As a result of INFO-Web being replaced, a series of compatibility webservice methods are no longer needed, as there are other and better ways to achieve the same results.
The following methods will be removed starting with version 3.7 (Fall 2016)
CreateAddiotnalWebUser (An old broken version of family/shared subscriptions)
All of these can somehow be replaced by using the User Register (See the user register introduction on the api documentation site).
Please note that the backend for usernames and passwords is not the same, if you want to migrate the users from the old backend to the user register there is an option for it in the INFO-Script helper application. Please contact Infosoft before you run the migration, it won’t destroy anything but it might be easier if you know exactly what it does.
The following methods have their behaviour changed:
The methods will do various verification checks against the INFO-Web username/password store, and update the username in cases where there is an email change. This behaviour is now removed so updating a customer will not directly affect a user.
To achieve the same thing, update the user while updating the customer.
As always, contact Infosoft support if you have questions regarding the changes.
The expected behavior (based on the input parameters) would be to retrieve all delivery addresses for the given subscription (CustomerNumber and Title) for the given date range.
However the actual behavior from at least v3.3 and onward to the latest version 3.5.1 is to retrieve all the customers addresses, regardless of title, in the given date range.
From version 3.6 the behavior will be changed so that it works as expected. For those of you relying on the current behavior we recommend switching to the GetAllDeliveryAddresses and filter the date range on the call site.
The change of behaviour will be noted in changelog number 11745
Occasionally we have a request for retrieving version information via the Web services API. Typically for two reasons, one is to manually figure out which runtime version is deployed when trying to resolve issues, that is some human needs to verify that the webservice behind the URL matches the expected version.
The other reason is for a client to programmatically figure out which version of the API to use in different circumstances, typically needed for hosted services targeting multiple Infosystems installations or for larger installations where multiple environment within the organisation runs on different versions.
Till now there has been no real support for such version discovery, but starting with version 3.6 we are introducing a service to discover the version. The version service will be available both as a plain HTTP GET resource (giving you json or xml) and as a SOAP service.
The version service endpoint is currently includes 4 version markers:
Product Version – that is the “marketing” version number including the current bugfix relase number
Database Version – the schema/data model version, typically of the form 3.6 or 3.5 or something like that.
Build Version – the complete version including build number of the web service instance. This could possibly vary if you have multiple installations with different bugfix builds. API wise the build number should not be relevant.
Greatest Client Version – the greatest version of the windows forms application that has been logged. This is basically just included for “humans”. If this is a larger sub version than the product or build version something is probably wrong. I.e. if this shows 3.6.1.X and the build version shows 220.127.116.11.12345 then bugfix release is not applied on the web services installation.
We will post the details of the endpoint on the documentation site when nearing the 3.6 release.
As some of you might know the configuration system in InfoSystems suite is quite flexible, and by now it has a lot of configurations. A little over 1000 configuration options in total, some are more relevant than others by now. The system as it is currently, is basically an evolution of the system that existed in the old VB6 suite of application (now dubbed Classic) – meaning the design is roughly 20 years old!
Surprisingly it has held out quite nice, and while we have had our concerns with it, there has been no real need. Now however, due to performance issues we had to re-write the entire set of management forms. Instead of just fixing the form to perform better we had a look at the structure of the thing.
Title based configuration values
Most configurations are related to a title, so that title A can have one value and title B can have another in case they do things differently. That’s all fine and very nice, but the data model is such that each configuration must exist once per title. Now imagine you have 70 titles in the database, and each instance of configuration “C1” should be the same but it should not be whatever default the system comes with: Then you have to go around and change 70 instances of “C1”, not exactly fun or time saving.
We are changing that, so now some of the configurations will allow you to set a default, with no title indication. Meaning that if a configuration “C1” is not defined for a given title “A”, the default value will be used. There are still going to be a few configurations that will require you to set a title as there is no “sane” scenario where having a shared default makes sense (there are possibly scenarios where you would want to do it anyway, but we have to deal with your insanity :))
Configuration as a service
One other thing that rebuilding the configuration system has allowed us to do, is to expose the values as a service. It is not often needed, but on rare occasions a web client might need to know a specific configuration setting or limitation value from the system in order to provide the best end-user experience. Previously this was impossible without digging into the database, so most people resolved to hard-coding the values, other resolved to build it into their own configuration system. Either way there was a synchronization issue only resolvable by human interference.
With the re-write there is now a read only service that will give you any configuration that you need. We are still discussing the options for creating and maintaining your own configurations but as of yet we have had no demands for such an extensible configuration service so we are holding it back for when demand arrives.
Maintaining Configuration Data When Needed (Reducing startup)
Depending on the amount of data in the various configuration tables, the startup time of the application suite, be it client, webservice or the jobscheduler, takes from around 15 seconds up towards 40-45 seconds in the worst scenarios (largest installations). Part of this is due to the fact that during startup a maintenance routine runs to ensure consistency between the database, and the various defaults that should exist in the system.
In reality this maintenance is only required in two cases, the defaults changed (with a new version) or someone messed around with the database manually. The latter case is unsupported in any event, but the first is the whole reason for the maintenance routine.
We are introducing a change to this maintenance system so that it is only executed ONCE per new version. I.e. the first person starting any of the applications on a new version will get the long startup time, usually the person doing the upgrade, while all others will skip the maintenance routine altogether. This will reduce startup time with anything from 2 to 15 seconds depending on the database speed and number of records to analyze for maintenance. For those with either a lot of overrides or even a few titles (4+) this should be quite noticeable.
So when will you be getting all this configuration goodness?
The short answer: v3.6.0
The slightly longer answer: Bits and pieces of it has already found its way into 3.5.0 and a bit more into 3.5.1, but you probably won’t notice any of it. The things described above will be fully implemented in 3.6.0 to be released sometime during Q1 2016.
Enough about the technicalities already, I want to see the damned result!
One of the fine features of a hardcopy (physical paper) is that it can be shared across the breakfeast table. Many of our customers have had an idea or a direct wish to support such a thing with the digital subscriptions they have. Previously we have only had support for this through a parameter “SharedSubscriptionCount” that could be defined on each subscription. This could then be used to minimize the number of accounts that could be connected to a subscription. All user mapping and handling had to be done on the outside.
We have now added the first steps to natively support subscriptions shared between multiple online users. There are now options to map users from an SSO/User system to a customer and one or more users to a subscription. Doing so exposes the needed functionality to allow a customer/subscriber to add users in his/hers household as users of the subscription. That information is then again available to the customer services. Depending on wether you use the Infosoft SSO backend or an external one, the feature set differs a bit, but by and large you should be able to get the same end result without having to maintain external user/customer mappings for shared subscriptions.
The use of this functionality requires some integration from the web client, and the endpoint required to do so are exposed as SubscriptionUser.svc. The technical documentation on how these services work can be found on the API Documentation site, and in the comming months we will be adding a guide/description of the various details the service exposes.
C-Web (the Infosoft self-service web client) already implements this feature, so some of you have had parts of this already for some time.
Note: SharedSubscriptionCount still need to be verified by the client if required and is not built into the SubscriptionUser service.
Just a quick reminder/announcement – the old Job Scheduler Service and the Email Listener service are both going to be removed from the application suite starting with version 3.6 which is scheduled to appear in the fall of 2015.
As mentioned previously a new scheduler exists, and it is used in production multiple places and it is time to move on.
Likewise the services provided by the email listener, can now be achieved using the new scheduler so there is no need for a separate service to handle this load.
Hopefully this should alleviate some of the current installation pains.