This release concentrated on
- Technology improvements
- Work Queue improvements
- Data localization
- GUI Extensibility
- Development tools (Architect) improvements
- Fixing bugs
This upgrade brings several big migration steps. Please read the documentation carefully.
- Import new Root and Security (AS Authorization before) packages using Architect File > Import Single Package
- Execute deployment scripts on these packages (in Architect - File > Run Update Scripts)
- We changed the user name under which the application server runs work queues and other stuff. Before you had to have an internal user in your
BusinessPartnertable which equaled to the user name under which your application server ran. It was typically
IIS APPPOOL\origamor something like that. From now on it will be a fixed user name -
origam_server. In order to migrate locate an entry of your internal user in the
BusinessPartnertable and change the
- Follow the How To Upgrade Web Application to OWIN article
- In case you use Windows Authentication or you want to migrate to the new ASP.NET Identity from a .NET Membership database follow Startup.cs User Management Configuration article
- If you use an LDAP Membership authentication provider (authenticating against an Active Directory domain) and you use the following key
key``=``"injectDomain"/>you need to convert this setting to Startup.cs using Active Directory Authentication Setup.
With this release we migrated to an OWIN middleware. OWIN is a new open source standard that decouples the application from the actual web server (IIS). It will allow us to be independent on the web server technology provided by Microsoft. There are also emerging native OWIN modules we will be able to get advantage of, like ASP.NET Identity.
The most visible difference of OWIN architecture is the way the web application is configured.
In ASP.NET you used to configure the web application using a web.config file.
In OWIN the whole configuration cannot be based on a web.config because it is an IIS tool. So from now on the application is configured using a Startup.cs file. As you can guess this is not a typical configuration file, instead it is a block of C# code.
In this version there are still some parts (modules and handlers) configured using web.config but the new security stuff is configured in the Startup.cs. We will migrate more parts from ASP.NET to OWIN in the future releases.
This release was all about security improvements.
- The application server is more secure now. We fixed some possible security gaps.
- Internal functionality is executed under an internal user which has no actual login (origam_server)
- Database password storage is now based on ASP.NET Identity framework with our own improved password storage. We still support Membership database for backwards compatibility but you can migrate to ORIGAM native database storage using How to Migrate from Membership to Origam Based Authentication.
- ORIGAM now supports 2nd authentication factor if needed. The only second factor we provide out of the box is e-mail. Contact us for help with other providers (e.g. using SMS).
We improved stability of the Mail and File Work Queue Loaders. They will now fail more safely when there are problems with loading work queues.
File loader now has some new features:
- Decompressing ZIP files
- Loading a batch of files as a single message (very useful for batch exports from other systems where you need to process all the files at once, e.g. in case of master-detail exports in multiple files).
See File Loader documentation for more information about configuring these features.
It is now possible to localize not only the model (screens, fields, messages) but also data (e.g. content inside drop-down lists).
It is now possible to extend GUI elements (screens and sections) from other packages in your package.
Now you no longer need to make full copies of your screen designs only because you want to add a new database field in your customer’s package.
You can create an extension by right clicking on your screen or section element and selecting New > Alternative. A new version of the original screen will be created in your package. This version will be used instead of the original version. You can make any edits to it as you want. Obviously when the original screen will get updated (new widgets added) your version will stay intact (you will need to add those widgets by yourself).
Debugging your application became a lot easier now with a possibility to see the server log inside Architect.
Server log setup:
- Publish the log file on your IIS server (typically it is already published e.g. if you store your log files under
AsapSettings/ServerLogUrl to contain a url pointing to the published log file.
That’s it. You will see incremental updates of your log directly in Architect.