Screen changes do not go through

Posted on February 26, 2009 by admin

After the update to HR.Net 3.0 we encountered a new problem: changes to screens/workflow forms done in Admin Console did not come up on the actual front-end. In the previous version it took about a minute to get the updated screen through the web-interface.. or login out-login back in did the job.

In this case all the magic we got used to did not work. We raised a question with Vizual about this.

First solution they came up with was to restart IIS server. So after all the people in the office wondered off home on Friday evening, I restarted IIS.. and hooray! changed did come through instantly.

That is only a part of the story.. a few weeks down the line, we noticed the same problem comes up again. Restarting IIS every day is not the best solution to this question.. So we asked Vizual again.

This time Vizual came up with different setup: we needed to change the settings in web.config file in the main installation of HR.Net.

Before I describe what to change, be aware, that every change to this file in the live system will lead to login out of all the users.. so do that when there are nobody working in the system. You can check who is currently loged in via this query run against your current HR.Net database:

 select userid
from oc_users
where loggedon='T'

So now you can go into web.config and do the magic: you need to find a string “<CacheExpiryInfo>“. This section will look something like this:

 <CacheExpiryInfo>
<XmlSerializerSection type="Common.Configuration.SectionHandlers.CacheExpirySettings,Common">
<CacheExpirySettings xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<PluginExpirySetting>
<PolicyType>epSlidingTime</PolicyType>
<Value>00:05:00</Value>
</PluginExpirySetting>
<GetDataExpirySettings>
<PolicyType>epSlidingTime</PolicyType>
<Value>00:05:00</Value>
</GetDataExpirySettings>
<ScreenDefsExpirySettings>
<PolicyType>epSlidingTime</PolicyType>
<Value>00:05:00</Value>
</ScreenDefsExpirySettings>
<FieldSecurityExpirySettings>
<PolicyType>epSlidingTime</PolicyType>
<Value>00:05:00</Value>
</FieldSecurityExpirySettings>
</CacheExpirySettings>
</XmlSerializerSection>
</CacheExpiryInfo>

Before this section there will be loads of comments explaining what is going on. What Vizual recomended to do is to change “epSlidingTime” to “epDisabled“, save the changes, wait a few moments until the change come through, and change it back to “epSlidingTime“.

I’ve done what they said. That fixed the problem.. But something was telling me that they have no idea what it is actually does. This way it only cleares the cache and nothing else.. so a week after there will be the same problem again.

I’ve changed the caching time from one hour to five minutes. That does the job, but very poor. It definately takes more than 5 minutes to refresh.

Turning the cache off is one of the possibilities, but might be risky to overload your server: every time somebody is bringing up a screen, it will be genereated from code, not taken from the cache. (At least I’m thinking it works like this)

Good luck with this one.. I’m still in the process of playing with this crap.. will keep you updated.

Posted in Admin Console, Applications Server, SQL Server | Tagged , , | Leave a comment

The way your data is retrieved

Posted on February 26, 2009 by admin

Recently we noticed a bunch of email notification going to folks with outdated information. I’ve checked the mailers in the workflows: information is taken via “Input table/Values/….”. And after some thought I came up with a question: when does the actual database read appears? Is it when the workflow instance is created? or when it is actually fired? You need to keep in mind that there might be workflows that are triggered a few weeks/months down the line after the triggering event..

So I’ve raised this question with Vizual and here is the reply:

“The “Input Table/Values” data is cached at the time the workflow instance is created. Data in a DB reader stage is retrieved when the actual workflow process runs. Therefore, even if the workflow itself does not run for a period of weeks or years after the instance is created, the input data will still relate to the snapshot taken at the time the instance appeared on the queue whereas any info taken from a DB reader will show the current data on the database at runtime.

It is also important to bear in mind that the input table values for any calculated fields will show the picture BEFORE the input record was inserted/updated. This means that for a triggered workflow firing on insert of a new record, the input table values for any calculated fields will be blank. When firing on an update, the input table values for calculated fields will be based upon the old values on the record prior to the update. For this reason, if referring to any calculated fields within a workflow, you should always ensure the values are taken from a DB Reader stage (i.e. read from the database at time of executing the workflow) as opposed to using the input table values. Any other relevant data that may have changed since the instance was created should also be read in the workflow (e.g. employee status may change in the period between creating a workflow instance and running the actual workflow process). “

Basically they say “DO NOT USE Input table/Values METHOD EVER!“. There is such a big potential for bugs in your workflow, I would never use this method again. My new rules are: create simple database reader for every database read you need. This way you will save yourself painful debug session few month down the line, when folks will come to you and claim they are getting incorrect data from the mailers.

Thanks to Vizual for providing such a great documentation about all the bugsfetures they have.

Posted in Admin Console | Tagged , | Leave a comment

Failed to insert a record via a Screen.

Posted on December 9, 2008 by admin

During the export of our legacy Issue Tracking system into HR.Net, I faced a problem that looks like this:

Error on Insert Record

Error on Insert Record

The error was saying that something inside HR.Net do miss field called NOTENO in table ISSUENOTES.

During the export of the information, I had to create this field that contained number of a note and this was a primary key in MySQL database. I have changed primary key to be GUID and deleted NOTENO. From my past experience I knew that deleting fields in HR.Net was bad and lead to different kind of errors. This is the case.

DONT EVER DELETE FIELDS FROM HR.NET TABLES!! you hear me?? )

I just hoped to get away with deleting extra filed.. but never managed.

First I tried to resolve the problem myself. I’ve recreated the screen which gave me the error – no luck. Remade the underlaying screen.. and nothing changed. And then 5pm hit my clock and I went home.

Next morning I spent 30mins on the phone with Vizual trying to resolve the problem. The support engineer has done the same steps: recreated the screens.. and guess what? nothing changed -) The guy tried different combinations of screens, recreated almost the entire system from the scratch.. and nothing changed.

At the end we remembered that we have triggers on this table. One of the triggers looked like this:

Problematic Trigger

Problematic Trigger

If you notice, this trigger has no fields to be run on. Normal trigger has at least one field that it is triggered on. I suppose that NOTENO field was here (before I deleted it from the table) and that has been causing the trouble.

We deleted this trigger and the problem was resolved. So every time you run into similar kind of problem, check your triggers!

Posted in Admin Console | Tagged | Leave a comment

Change the start number of autogenerated field value

Posted on December 8, 2008 by admin

Sometimes you have auto-generated fields in tables. Most of the times this field is a ID-number of an item. And not every time you want to start numbers from 0.

For example, I have to export some historic data into a table with auto-generated number. I have 250 records to go in, so next number I want to see from the system is 251 or higher. But you can not change the starting point, and system is trying to count from zero. This leads to a unique field errors: “The record which is being saved contains records which must be unique within the database. ”

Auto-generated field start value is disabled

Auto-generated field start value is disabled

This can be avoided.

Go into database that serves your HR.Net and find table called OC_KEYGENERATOR. This table works as a counter for all the auto-generated fields in the system. So find the record with KEYID = “Table_field” and change the values of KEYVALUES and LASTUSEDVALUE to a desired counter start number. Make sure you put in relevant number: if you want next auto-generated record to be 251, then make KEYVALUES=251 and LASTUSEDVALUE=250. And so on.

Obviously, this hack is not documented in any of the Vizual documents.

Posted in SQL Server | Tagged | Leave a comment

Database writer stall error ‘Cannot set Column ‘XXXX’ to be null’

Posted on September 10, 2008 by admin

Describes a stall error that can occur on a database writer when writing lookup values – ‘Cannot set Column ‘XXXX’ to be null’. Please use DBNull instead.
Workflow stalling at the database writer stage with the following error:

Exception: Cannot set Column ‘XXXX’ to be null. Please use DBNull instead.

Steps to recreate the issue:

1. Create a workflow and place a lookup on the workflow from.
2. Place some Filtered Lookups(on a Repeating Section which is placed on a Tabbed Folder) filtering on the previous lookup field
3. On a Database Writer, map the Primary Key to the Repeating Section ID and map these filtered lookups to some Text fields on the table.
4. Submit this form without selecting any values on the Filtered Lookups.

The Database Writer will stall with the above message.

It is failing because of the way the mapping is defined in the database writer for this lookup field. It will have been mapped to the ‘Primary Key’ value of the lookup (eg. Input Form\REPORTSTO\Primary Key) and if there is no data it is unable to lookup the primary key for the item.

How to resolve the issue:

Either change the field types on the writer table to Lookup rather than Text or prevent workflow forms from being submitted that have blank filtered lookups via the ‘Cannot be blank’ property box.

OR Amend the Database Writer mapping to map to the field on the input form rather than using it’s primary key.
For example, replace:
Input Form\REPORTSTO\Primary Key
with:
Input Form\REPORTSTO

Posted in Admin Console | Leave a comment

Error saying “Violation of PRIMARY KEY constraint ‘OC_WORKFLOWCACHEPARAMETERS_PK'”

Posted on August 30, 2008 by admin

Talking about an issue that can occur that results in a stalled instance in the Workflow Instances with the error as described.

Viewing the Workflow stalled instances displays the following error message.

Exception: Violation of PRIMARY KEY constraint ‘OC_WORKFLOWCACHEPARAMETERS_PK’. Cannot insert duplicate key in object ‘OC_WORKFLOWCACHEPARAMETERS’

Unstalling the instance will result in the workflow continuing to the end without incident (not every time).

This occurs when a workflow process has mapped database writer parameters that exceed the allowed limit (103 characters) in SQL.  The workflow may stall on the Database Writer stage causing the problem or on the stage immediatley following the Writer.

This issue can be resolved by reducing the amount of text contained in the database writer mapped parameters.

For example:
Database writer has a parameter of:
Input Tables\Values\Operational Team\Operational Group\Operational Department\Operational Division\Divisional Head\Full Name

Use a Database Reader prior to the writer to retrieve the Divisional Head\Full Name.

This will allow the mapped parameter to become:
DatabaseReader\Full Name.

Posted in Admin Console | Tagged , , , , , | Leave a comment

Incorrect Foreign Key Data returned in a table trigger if the child data is opened from a data grid

Posted on August 30, 2008 by admin

This article describes an issue that occurs when a table trigger is fired by the editing of a child table that has been opened from a screen that is not the parent.

Description of the problem:
1. A table trigger is configured to fire when a child table of People (for example, but this can be any other table) record is modified (i.e. Application Detail)
2. The trigger is configured to use information in (DB-readers or mailers) containing details taken from the Foreign Key Record (People Table).
3. When the workflow is triggered from the screen with data grid not based on parent table, the Foreign key is taken from the table which is a base for the screen, not the original key stored in the table.

How To Recreate
1. Create a Vacancy Table. This table should be defined as a top level table.
2. Create an Application History Table as a child of the People table. This table must have a lookup to the Vacancy Table.
3. Create simple screens that allows you to create a vacancy and application history record.
4. Create another screen as follows:
1st Dataset Parent Table = Vacancy
2nd Dataset Table = Application History
5. Join Dataset 1 to 2 via the Vacancy.Vacancy_ID = Application History.Vacancy Lookup
6. Add Dataset 2 information to the Vacancy screen via a datagrid that opens the simple application history screen you created in step 3.
7. Create a workflow table trigger on the Application History table that sends a message to the ANADMIN account and contains data from the
FOREIGN KEY PEOPLE record (i.e. Full Name, FirstName, Date of Birth)
8. Create the actual trigger so that it fires whenever any change is made on the Application History table.
9. Login to the Web App and using the screen and datagrid created in 4 navigate through to an Application History record, modify some data and hit
save.
10. The expected FK – PEOPLE fields will be blank in the message.

This is a known to Vizual issue that has been raised with development for resolution in a future release.

Workaround from Vizual:
The following workaround is available (Please see symptoms of issue as this resolution relates to that information):
1. Create a new field on the Application History table called Related People Record. This should be a lookup to the People table.
2. Populate the Related People Record field with the Foreign Key data when the record is initially created.
3. The message can be created using this lookup as opposed to using the Foreign Key information.

This is quite hefty solution. Some better ideas came to my mind.

Better Workaround:
You need to amend the triggered workflow – in the begining of the flow, just add another Database Reader that takes Foreign Key from the table, and in the following stages refer to this reader with foreign key, not the one you can take directly from Input Table.
This way you don’t need to change the table structure and multyply table fileds, having duplicative information stored in the same table, which can lead to the further bugs.

Posted in Admin Console | Tagged , , , | Leave a comment

Unable to send Mail-Merge to hard-coded email

Posted on August 16, 2008 by admin

Unfortunately, although the Mail merge stage allows you to select a hard-coded email address, this option doesn’t currently work.

When you are trying to send a Mail Merge to hard-coded email address, it fails to do so. It does not stall, does not display any errors. It just does not send email.

What you need to do is to create a new user record and assign the required email address to this user account. On the mail merge stage, you can then select the “E-mail User” option and “select from a list of users” and select the user account you have created. The mail merge will then be sent to the required address.

Posted in Admin Console | Tagged , , | Leave a comment

Mail Merge stage in workflow not sending to recipients mapped from a Database Reader

Posted on August 16, 2008 by admin

This article describes an issue that can occur with Mail Merge stages when using the recipients option “Message User” in conjunction with a list of people returned from a database reader.

When using a database reader to determine the recipients of a mailmerge, if the reader returns any People records that are not associated with a user account then the document will not be delivered to any of the intended recipients but will instead be sent to the ANADMIN user only.

There is no failure message, stalled instance etc to indicate what has occurred or why it has occurred

Example of how to re-create the error:

  1. Setup a Workflow
  2. Create a Database reader stage that returns two PEOPLE table record (ensure that one of the People records is associated with one, and only one user account and that the second People record is not associated with any user account).
  3. Create a Mail Merge stage and on the Message tab, select the first option (Message User) and map this to the Database Reader stage.
  4. This will send the mail merge document to ANADMIN only.

There is no proper solution for this problem – this was reported to Vizual for future development.

The only advice is to be careful and ensure that all People records returned by the reader stage have an associated user account set up within the Admin Console.

Posted in Admin Console | Tagged , | Leave a comment

Error ‘Invalid Argument.” when using the Web App – Navigator

Posted on August 14, 2008 by admin

Describes an error that can result in the following error message when using the Navigator on the Web App. Error:    Invalid Argument

Symptoms: If you select an Application type and then select a Table, before the system has refreshed, the following error message is displayed and the navigator needs to be reloaded.

An error has occurred in the script on this page.
Line: 138
Char: 4
Error: Invalid Argument
Code: 0
URL: https://servername/hrnet

Do you want to continue running scripts on this page?

Click “No” on the error dialog and then click on the Navigator button to reload the navigator screen.

Before choosing a table after changing the Application Type ensure that the navigator has refreshed prior to choosing the table

Posted in Uncategorized | Leave a comment