HOME COMMUNITY BLOG
Skip to end of metadata
Go to start of metadata

Release Goals

  • Installation package
  • Simplifying new project creation
  • Migration of Architect and Desktop Client to .NET 3.5
  • Contextual help in Architect
  • Improving ASP.NET Identity integration
  • Self-Registartion
  • Streamlining the Rule Model
  • New built-in SuperUser role
  • Possibility to delete BLOB field contents
  • Report exposal through API
  • Fixing issues

Migration

The migration from the previous release (2015.4) is pretty straightforward. If you migrate from an older version you need to go through the previous migration steps.

  1. Update the Architect (or install a new one using the new installation package – a preferred method).
  2. If you installed Architect using the installation package, copy AsapSettings.config from your old Architect to the newly installed one (\Program Files (x86)\ORIGAM).
  3. Open Architect, select your project and answer Yes to the following popup dialog:
  4. This will update your model structure to the latest version.

    IMPORTANT

    This version will store a model structure version information in the exported model XML files. Model files saved using a different version will not open in Architect. You need to export all your packages to XML again using this version of Architect in order to be able to load them later on. Old files will not open.

  5. Import the up-to-date versions of Root model packages (Root, Security, Root Menu – if used)
  6. Save all your packages again into XML if you are using a source control versioning system (e.g. GIT).
  7. Update the application server(s) using the update package (copy all files from the .ZIP file over your application server files)

Installation Package

We finally figured out the best way how to install ORIGAM platform flawlessly. From now on you can download the new installation package.

The package just installs Architect plus a complete template of the application server and root model of the same version. These will be used by the New Project wizard (see below).

Unified Build Versions

Until now every product (Architect, Application Server, Desktop Client...) had its own build number (e.g. 2015.4.0.50). Since the code base is shared between the products and there are strong dependencies between them (e.g. on the Root package), we unified the build numbers. From now on all the products share the same build number so you can easily recognize if you are using the same version across the installed applications (e.g. same Architect and Application Server).

Side-By-Side Architect Installation

As we know that some customers are conservative and use a stable version for a year or more and some customers go on the bleeding-edge of the latest-latest, we implemented the installation package so you can run several different stable versions side-by-side.

Example:

  • The current version will install as ORIGAM Architect (2015.7)
  • When you update this version (download a newer build) it will overwrite this version, keeping your 2015.7 Architect up to date.
  • When you download the next version it will install as an independent product, in a different folder (e.g. ORIGAM Architect 2015.11)
  • You will convert some projects to the newer version (moving your settings from the old to the newer Architect) whereas the conservative projects will stay on the previous version.
  • After all the projects get migrated from one version of Architect, it can be uninstalled safely.

New Project Wizard

You can find a new menu item File > New Project in Architect. It will help you set up a new environment for a project including:

  • Configuring Architect settings
  • Creating empty databases
  • Importing the root model packages
  • Creating a new package
  • Setting up a new website

The only prerequisites are:

  • An instance of SQL Server
  • Locally installed IIS Server (the wizard does not support a remote web server)

The only thing you will have to do is to name your project and provide a database server name. The rest is done automatically.

The wizard will use files contained in the Project Templates\Default folder created by the installation package. It contains an up to date root packages and an application server template. It will also set up a web server for you and configure it appropriately.

You can start developing right after the New Project wizard finishes.

Migration to .NET 3.5

It's here. We finally migrated our desktop applications to .NET 3.5. This paves the path for future migration to .NET 4 and removing some obsolete components we have been using. The functionality remains the same for now.

You may find inconsistencies with the previous version of Architect or bugs. Please report these to us on the community.

Contextual Help In Architect

You can now press F1 (or go to the Help menu) and a browser with this documentation will appear. If call out help while editing a part of the model, you will be redirected to the appropriate topic automatically.

Some of the documentation pages are still not finished and are empty. Please be patient, we will be working on the documentation in the following weeks a lot.

Improving Asp.NET Identity Integration

The user management now allows the administrator to confirm the user's e-mail manually. Also it is now clear if the account has been locked – the Unlock button will only appear in such a case.

The IdentityService sequential workflow service adapter also contains additional methods for managing users.

Self-Registration

It is now possible to turn on a built-in self-registration page using appSettings/userRegistration_Allowed = true. This will allow a new user to sign up to your application. After entering his name, e-mail and a password he will be sent a confirmation e-mail. After confirming he will be able to log-in to your application. An initial user role can be configured using appSettings/userRegistration_DefaultRoleId.

Additionally appSettings/userRegistration_MailSubject, appSettings/userRegistration_MailBodyFileName must be set. Placeholders for the mail body file are:

<%Token%> – e-mail confirmation token

<%UserId%> – user Id

<%UserName%> – user name

<%Name%> – name

<%FirstName%> – first name

The default token confirmation URL format is http://yoursite/ConfirmEmail?token=<%Token%>&userId=<%UserId%>. This has to be provided in the e-mail body so the user can click and finish the registration.

Register and ConfirmEmail pages need to be configured accessible by an anonymouse user.

Streamlining Rule Model

We used to have two options in the old Architect – Start Rule (which was basically any kind of an XPath based rule) and an End Rule (XSLT based rule). These were used in different scenarios with different input context formats. All the rules were always provided in rule list so you could easily choose an improper rule type in the model.

From now on we are introducing the following rule types:

Condition Rule

An XPath based rule that always returns a boolean value.

Input context: Full document. /ROOT/value in case of simple data types (string, integer etc.)

Used in:

  • Sequential workflow start rules
  • Data Structure rules conditions
  • Workflow page (API) Redirect action – ConditionRule
Validation Rule

An XSLT based rule that returns a RuleExceptionDataCollection type.

Input context: Full document.

Used in:

  • Sequential workflow task – EndRule
  • XSLT Data Page API – SaveValidationBeforeMerge
  • UI Action – ConfirmationRule
  • Screen Menu Item – ConfirmationRule
  • UI Sequential workflow task – SaveConfirmationRule
Validation Rule Lookup XPath

An XPath that should return a string containing a Validation Rule. Typically this will be AS:LookupValue function that will load the user created validation rule from the database.

Input context: Full document

Used in: see Validation Rule

Entity Rule

An XPath based rule used for evaluating entity-level conditions.

Input context: /row (e.g. /row/@EntityFieldName)

Used in:

  • Conditional Formating Rule condition
  • Entity Field Dynamic Label condition
  • UI Action condition
  • Workflow UI Action Script Call condition
  • State machine transition condition
Complex Data Rule

An XSLT based rule used for enforcing rules on data (calculated fields).

Input context: Full document

Used in:

  • Data Structure Rule Set
Simple Data Rule

An XPath based rule used for enforcing rules on data (calculated fields).

Input context: Full document

Used in:

  • Data Structure Rule Set

SuperUser Role

When you created a new application role (e.g. using New Menu Item action) you had to the user management and assign the role to yourself before being able to test it. Also when you upgraded your customer's application the administrator would have to go through all the newly created roles and assign them first to himself to see what these new menu items contain.

From now on there exist a built-in SuperUser role to which every newly created application role (using actions) will be assigned. You will be (as a super user) immediately able to see the new menu item after running the deployment script containing the new application role.

Delete BLOB Field Contents

The BLOB field widget now contains a new option Delete which will delete the contents of the blob field. The web based version of the widget was also redesigned so it contains all the commands not as icons but as a context menu (aligned with the desktop version).

Report Exposal Through API

The API model now contains a new ReportPage element. It allows you to select a Report which will be returned to the callee. It is now possible to include modeled reports in your HTML applications.

  • No labels