This was a really weird one. A client’s application suddenly suffered from this error in all environments simultaneously. The root cause had nothing at all to do with K2 blackpearl, but it affected the service keys of the instance of a service, which brought down the service and caused the exception.
I can’t recall the last time I’d been this excited about building a new feature.
My client has a high-touch, high-visibility application — and I mean “high-touch” more in the sense that a lot of people use it, rather than it gets used often (quantity as opposed to duration, I guess). At the top of my clients’ Christmas list this year was a new feature for building and persisting reports that can be used to monitor the progress of work items through their process.
I wanted to build them a reporting engine that was flexible enough to provide insight from multiple data sources, and with an interface that was as familiar and intuitive as possible.
Pickers are rather odd controls in that they appear much like a textbox but can behave like a choice control. As such, one can’t simply use a “transfer data” rule action to populate them.
A big thing to watch out for when you’re building an application in K2 blackpearl with an RDBMS back end is an understanding of how to treat datetime values.
K2 uses the value
scnull to indicate a NULL value. This becomes especially important in SmartObject calls down to, say, stored procedures in your database.
The problem is, you can’t pass a value of
scnull into, say, a workflow datafield that’s expecting a datetime value. For that, you have to use an actual datetime value like
All of this manipulation can make things pretty hairy when you’re trying to feed a SmartObject and start a workflow at the same time. If your datetime value is on a SmartForm, and you anticipate having to deal with blank or NULL values, you might consider adding a hidden data label or two and expressions to go along with them. That way, you can convert the calendar control value into something useful for the database in one data label, and something useful for data fields in another.
I was having trouble with a SmartForm view recently — I couldn’t figure out why execution of this SmartObject method was taking so long! I could execute the SmartObject from within the SmartObject Services Tester and it would complete in less than a half-second; I even went down further and ran the procedure directly from SQL Management Studio… everything at the data layer looked “clean and green.”
I was recently tasked with creating a series of editable SmartForm views based on some that already existed elsewhere in the application. One of the views was based on a SmartObject that contained a series of ID’s pointing to other database tables. The task was to have the list view list the text of the records the ID’s pointed to — not the actual ID’s. Makes sense – to display a value of “1” probably isn’t going to mean anything to the user, but a value of “ALL” will.
Doing this in the list view is the job of the List Display control. The List Display lets one configure the relationship between the SmartObject value and another value in a different SmartObject.
I had thought that my task should be relatively easy — save the original view as the view I was creating, change a little wiring, and I’d be good to go. Not so. For reasons I don’t understand, I simply could NOT make the the properties of my “new version” of the old list view resemble what I needed for the List Display to work.
In my case, it was just easier to start over.
And I found that starting over was exactly what I needed — everything fell in line effortlessly — so much so that I’m a little mad at myself for spending so much time yesterday on trying to make my former approach work.
All to your benefit — because I’m about to walk you through using a List Display object in an editable SmartForms View.
In the second post of this series I showed how you could use XML functions to return your recordset from the database as HTML
row and cell elements (“Make the Database Return Your Recordset as an HTML Table — Using XML”, 8/6/2016). We did this by naming the XML elements after the appropriate HTML elements.
If we stopped at this point, we could create a SmartObject that returns our string of HTML
data to the caller. For example, we can already have the HTML for the rest of the report elsewhere, and this SmartObject simply “plugs in” the data to be displayed. This could be as easy as concatenating strings (say, an HTML report header, the HTML
output from the SmartObject, and an HTML report footer) in a Data Event.
We can go further. By using XSL Transform, we should be able to have the database return our entire HTML report — not just the table.