GMSC Workflows – Logging errors into a database

The GMSC logger is doing a great and useful job on both client and server sides.

On the server side (.NET), the GMSC team implemented logging using one of the most popular and powerful library – log4net. With the proper configuration, you can set the library to log errors in many different places like: console, text files, databases (MS SQL, MS Access, Oracle, …), SMTP etc.

In this blog post, I will show you how to configure log4net, in order to log errors into a database table.

Before we start, let’s first check the log4net initial configuration inside the Web.config file, from the “../GMSC/Workflows/” directory. It should look like this:


<appender name="WorkflowFileAppender" type="log4net.Appender.RollingFileAppender">

<appendToFile value="true" />

<file value="Log\Workflow.log" />

<staticLogFileName value="true" />

<rollingStyle value="Size" />

<maxSizeRollBackups value="15" />

<maximumFileSize value="2048KB" />

<layout type="log4net.Layout.PatternLayout">

<conversionPattern value="%date{dd.MM.yyyy HH:mm:ss} %-5level - %message%newline" />




<level value="WARN" />

<appender-ref ref="WorkflowFileAppender" />



Here you can see that an appender has been configured, and it’s of type “RollingFileAppender”. This means that the logger is set to save logs inside a text file (“Workflow.log”), but it does more than that. After the file reaches the maximum file size (in our case 2048KB), the logger will create another file (“Workflow.log.1”), and will continue writing logs inside that new file, and so on until the maximum size roll backups is reached (15), and the files are overwritten again, starting with the first one.

Before creating another appender, let’s first create a separate database (“LOGS”), having one table (“Log”) – it is a best practice to have a separate database for logging, because it can reach big sizes, and you don’t want to affect your other databases with that.

I’ve used this script to generate the table:

CREATE TABLE [dbo].[Log] (

[Id] [int] IDENTITY (1, 1) NOT NULL,

[Date] [datetime] NOT NULL,

[Thread] [varchar] (255) NOT NULL,

[Level] [varchar] (50) NOT NULL,

[Logger] [varchar] (255) NOT NULL,

[Message] [varchar] (4000) NOT NULL,

[Exception] [varchar] (2000) NULL



Fig. 1 – Database structure


In order to log all the errors into the “Log” table, we will have to create another appender, like this:

<appender name="MsSqlAppender" type="log4net.Appender.AdoNetAppender">

<bufferSize value="100" />

<connectionType value="System.Data.SqlClient.SqlConnection, System.Data, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

<connectionString value="data source=localhost;initial catalog=LOGS;integrated security=false;persist security info=True;User ID=****;Password=****" />

<commandText value="INSERT INTO Log ([Date],[Thread],[Level],[Logger],[Message],[Exception]) VALUES (@log_date, @thread, @log_level, @logger, @message, @exception)" />


<parameterName value="@log_date" />

<dbType value="DateTime" />

<layout type="log4net.Layout.RawTimeStampLayout" />



<parameterName value="@thread" />

<dbType value="String" />

<size value="255" />

<layout type="log4net.Layout.PatternLayout">

<conversionPattern value="%thread" />




<parameterName value="@log_level" />

<dbType value="String" />

<size value="50" />

<layout type="log4net.Layout.PatternLayout">

<conversionPattern value="%level" />




<parameterName value="@logger" />

<dbType value="String" />

<size value="255" />

<layout type="log4net.Layout.PatternLayout">

<conversionPattern value="%logger" />




<parameterName value="@message" />

<dbType value="String" />

<size value="4000" />

<layout type="log4net.Layout.PatternLayout">

<conversionPattern value="%message" />




<parameterName value="@exception" />

<dbType value="String" />

<size value="2000" />

<layout type="log4net.Layout.ExceptionLayout" />




Now, the appender is of type AdoNetAppender, which means that it works with a database. The events are written in batches of 100 (BufferSize). The ConnectionType specifies the fully qualified type name for the System.Data.IDbConnection to use to connect to the database. The ConnectionString is database provider specific. The CommandText is either a prepared statement or a stored procedure, in this case it is a prepared statement. Each parameter to the prepared statement or stored procedure is specified with its name, database type and a layout that renders the value for the parameter.

In order to make use of the newly created appender, you have to add it to the root element of the log4net configuration:


      <level value="WARN" />

      <appender-ref ref="WorkflowFileAppender" />

      <appender-ref ref=" MsSqlAppender " />


Now, both appenders will log the errors. You can have one or more appenders running at the same time, it all depends on how the configuration is done.

Next time when an error will occur, you’ll be able to see it:

– in the database

Log in database

Fig. 2 – Log in the database

– in the Worflow.log file:

Log in Workglow.log

Fig. 3 – Log in the text file

You can even create your own workflow, showing all logs:

Log in workflow

Fig. 4 – Logs in a workflow

You can find bellow the code used for this simple workflow:

– WorkflowSettings

<?xml version="1.0" encoding="UTF-8" ?>
<WorkflowRoot xmlns:xsi="" theme="FlatTheme">
<WorkflowNode id="0" label="Home" >
 <WorkflowNode id="1" label="Overview" controller="List" form="LogsForm" follownode="10">
 <WorkflowNode id="10" label="Read" controller="Form" form="LogsForm" follownode="1">

– FormSettings

<?xml version="1.0" encoding="UTF-8" ?>
<FormList xmlns:xsi="" >
 <Form name="LogsForm" table="Log" idfield="Id" order="SQL[Order By Date DESC]">
 <FormTab name="GeneralTab" label="General" >
 <FormGroup name="DetailGroup" label="Details">
 <FormField name="Id" type="textfield" datatype="number" required="false" visible="hidden" />
 <FormField name="Date" type="textfield" datatype="string" required="false" maxlength="50" visible="form,list" editable="false"/>
 <FormField name="Thread" type="textfield" datatype="string" required="false" maxlength="50" visible="form,list" editable="false"/>
 <FormField name="Level" type="textfield" datatype="string" required="false" maxlength="50" visible="form,list" editable="false" />
 <FormField name="Logger" type="textfield" datatype="string" required="false" maxlength="50" visible="form,list" editable="false"/>
 <FormField name="Message" type="textarea" datatype="string" required="false" visible="form" maxlength="50" editable="false"/>
 <FormField name="Exception" type="textfield" datatype="string" required="false" maxlength="50" visible="form,list" editable="false"/>
 <FormAction name="List" action="SCRIPT[IG.navigate(1)]" visible="form" />

For more informations about configuring log4net check this link.

Posted in Uncategorized | Tagged , | Leave a comment

GMSC 2014 Workflows in IE 11 – compatibility issues


When first trying the new GMSC 2014 Workflows on the latest Microsoft browser (IE 11), you’ll find out that some controls (or at least one), will not respond as expected.

For example, I found out that when having a list, with some triggering action set on it’s elements, the click event won’t respond.

It seems that this is not a GMSC problem, but more of a Kendo UI one. The “Telerik guys” have introduced IE 11 support starting with version 2013.2.918, but since GMSC 2014 has been released earlier, it only contains Kendo UI v2013.2.716, so no full Internet Explorer 11 support.

Solution 1 – Update the Kendo UI framework

One solution would be to update GMSC, and to replace it’s Kendo UI framework with the latest version (currently v2013.3.1316). This will fix all the compatibility problems.

Be aware that this is not the recommended solution, because it may break down some of the GMSC internal libraries.

Solution 2 – Downgrade to lower IE versions

A second solution would be to force the Internet Explorer 11 to render your page as if it was IE 10, or lower.

Forcing the browser to render as IE10, for example, can be accomplished by adding the following meta-tag inside your GMSC web pages:

<meta http-equiv="X-UA-Compatible" content="IE=10">

To be able to do this, just download this sample of _RootMaster.cshtml, and place it in the “../Workflows/Views/Shared” application directory. This will override the current master page, and you’ll get the necessary meta-tags added to every workflow page.


Until a new version of GMSC, this can be a quick workaround for running workflows inside IE 11, so feel free to make use of it.

Many thanks to Franz Buchinger, who helped me work this out.

Posted in Uncategorized | 1 Comment

For those who use Notepad++ to create/edit workflows


When creating/editing workflow xml files, we make intensive use of Notepad++.

Usually, we format the text visualisation by applying the „XML Language” format. This seems to be very good, but it may get even better.

For this we’ve created an extension so that we are able to see the incorrectly spelled GMSC key words, and also to have intellisense while writing.

After we apply the new language format, our workflow will transform from this :

No language

to this :

GMSC language

If we mistype a GMSC specific keyword, we’ll get notified :


Also, when pressing Ctrl+Space, we will get an autocomplete control, having all the possible suggestions.



Feel free to download this extension from here .


To install it, you have to take the following steps:

1. Unzip

5. Unzip

2. Open Notepad++ -> go to Language -> Define your language

6. Define your language

3. Click Import and give the path to „GMSC Language.xml”

7. Import

4. For intellisense, copy „GMSC.xml” file to „C:\Program Files (x86)\Notepad++\plugins\APIs” directory (or where the notepad++ is installed).


5. Reopen Notepad++ and enjoy

Posted in Workflow Editor | Tagged , | Leave a comment