At some point, you might find yourself getting confused by fields with similar names or identical names from disparate sources. It happens.
My client has an older version of K2 blackpearl/K2 SmartForms, and is preparing to upgrade to the latest minor upgrade in version 4.
Here are my tips for upgrade prep.
Given a SmartForm with the same item view attached to it three times, like rows: View A at top, View B in the center, and View C at bottom. Each view contains a series of controls, including a picker. Events on the view are wired such that the selections of the controls are recorded in a data label as each was made, So a dropdownlist control set to “I”, a radio button list with “am” selected, and a picker control set to “asleep” would give us a value of “I am asleep” in the data label.
I was seeing a peculiar behavior wherein the entire value of the data label in View A was being wiped out after the picker resolved, but the same combination of controls and values were working just fine in subsequent views. The same was also true if I skipped View A and used View B.
One of the greatest things about my position is that I get to learn from the very best in this field.
I’m used to using K2’s tools — K2 Studio and K2 Designer. I’m used to consuming SmartObjects via the Object Browser in K2 Studio or from within the Designer. Those SmartObjects are generally enveloped within some sort of category structure.
Say you have a stored procedure you’d like to expose as a SmartObject. Let’s do that using K2 for Visual Studio instead of K2’s native tools.
(Before continuing, ensure you have a copy of Visual Studio, with K2 for Visual Studio and configured for your development K2 and a database environment with stored procedures.)
I’d recently been plugged into a new project and asked to determine what specific tables or views were needed to move into a new environment. Apart from being unfamiliar with all of the data layer clockwork, I also didn’t have access to the RDBMS.
My first stop was to the SmartForm, to identify the SmartObjects involved. I could find the calls within the rules.
My next stop is the SmartObjects Service Tester. I found each of the SmO’s and right-clicked to view their XML. To get the code out of the form window, I selected all and copied it into a blank text file, then started going through the XML to find the objects they were predicated on.
The XML gave me the names of table or view objects the SmO was built upon. If the SmO was derived from a stored procedure in a package, the XML gave me the name of the package and the name of the procedure, which I could then pass along in a request to the DBA’s.
The format of a SmartObject based on a database object resembles this:
* if you have a SmartObject with a single method, the tag will read
The information under the
<serviceinstances> node will name the service instance and identify the GUID and type (e.g., type=”SourceCode.SmartObjects.Services.SQL.SqlServerService”).
The information under the
<objects> node will identify the objects the SmartObject is based on (e.g., “<object name=’usp_getShoeColors’ type=’StoredProc’ active=’true’ version=”>”).
So in that text file you dumped all that XML into, do a search on “<serviceinstances>” or “<objects>” to get to the information you need fast.
This is an enhancement I’ve really wanted to see: SmartForms Rules in version 4.6.9 now have name and description properties. Much like comments in code, these should be immensely helpful for developers new to a project who have to figure out what rules do what.
Let’s say a person actions a Process Instance in your workflow, but the item seems to “disappear” unexpectedly — routed to a special queue for workflow administrators because of an error condition. It would certainly be nice if the “actioner” was notified about the problem too, right?