Better BPM – 9




This ninth post in the Interaction Profiling series demonstrates the simplicity of the user maintenance aspects of the SOPS prototype application.  All of the SOPS Interaction Profile metadata is stored in the database following the designs presented in the earlier posts in this series.  The screens used for maintenance of this data are presented, commencing with the profile definition data, then illustrating the BPM Task and Role data and finishing wth the field validation form.


As an example of the profile metadata maintenance, figure 7 following, depicts a profile definition screen for one of the SOPS profiles. SOPS contains 23 profile definitions, plus 2 profile definitions used for ad hoc reporting, as Interaction Profiling, serendipitously, happens to provide an easy to use vehicle that gives end Users a really simple method of implementing ad hoc reporting in an application. All of the SOPS profile definitions are equally simple and contain minimal data. In fact all 23 non-reporting profiles are implemented with just one Profile Attribute and only the 2 demonstration ad hoc reporting profiles have more than one profile attribute (both profiles requiring two attributes). There is no doubt that this minimal degree of complexity is easily manageable by User supervisory personnel.  Click on the figure below to view a clearer image.



The above example shows the Profile Type drop down combo box, illustrating the four different Profile Types implemented in the SOPS prototype. Any Profile may be restricted to validation processing, or BPM logic or both, or be used for Reporting purposes only (ad hoc reporting essentially). SOPS provides filtered reporting capabilities and an Interaction Profile drop down is included on the filter criteria form that allows the specification of a profile for report filtering, together with other relevant application fields. All profile types can be used to filter reports. The profile type is used to optimize the profile matching logic, as only the appropriate types will be selected for matching, depending upon whether the purpose is for validation, or BPM, or reporting. If additional, profile-related functionality is designed into a framework, this profile type enumeration would have to be adjusted accordingly. The profile depicted in the example (Charity), is defined with the one criterion, Trade Category (one of the 15 profile attributes required in SOPS) having a value of “Charity”. This minimal level of complexity is clearly easy for Users to manage, although a non-production (User acceptance testing) environment would be required for initial testing. Note that the transaction value for Trade Category will default to Retail based on the example screen if the actual transaction value is missing (the Null default).


The profile attribute specification is equally simple, as most attributes map directly to an application field including the Trade Category. Here, in figure 8, is an example of the definition of the Trade Category profile attribute.



Only one prototype Profile Attribute could be considered tricky in any way and that is the Age In System, calculated Attribute. This is not really an issue as Profile Attributes are almost always defined during the development phase and the metadata will of necessity be created initially by IT developers for testing purposes. Figure 9 shows the details for this attribute definition.



Note that this attribute does not map to an Application Field, but is defined as a calculated formula. “Date() – CDate(‘%DateReceived%’). A few things require clarification here. The specification field, SQL Query, is somewhat misnamed, as SOPS allows either a Transact SQL Statement or an actual Visual Basic for Applications (VBA) code snippet / expression that returns a value. VBA is the language embedded in all Microsoft Office products and has been around for a couple of decades now. Although not considered an object orientated language per se, it is nevertheless extremely powerful and, given the use of Microsoft Access for the GUI, was an obvious choice for SOPS. VBA includes an Eval function that takes a string argument and executes it as VBA code. This is similar to .Net’s dynamic reflection capability, but somewhat simpler to implement.


The second point of clarification is the use of a tokenized string, “%DateReceived%”. SOPS implements this capability by parsing any tokens in any of the evaluation strings and replacing them with the contents of the current transaction’s field of the same name. Thus the %DateReceived% token is replaced at runtime by the current transaction’s field value that is named the same. The CDate intrinsic VBA function converts the string argument to a DateTime value. Thus the statement shown above is evaluated as today’s date (the date() intrinsic function) less the DateReceived field on the current transaction converted to a Date value. VBA returns this difference in days, which is exactly what we want for our Age In System attribute. As you can see, the field names are significant if a convention of this kind is used, so it would be a good idea to use easy-to-understand names for the transaction fields, given a few of the supervisory Users will be exposed to this conventional approach.  Now let us take a peek at the Tasks and Roles maintenance.


Figure 10 above depicts the SOPS maintenance screen for the Profile Task and Role data. Click on the graphic to see a clearer image. The top half of the form is a grid of the Profile Tasks for the profile selected in the top combo box.  The bottom half of the screen is a grid of the Roles that can perform the Task as selected in the top grid.  As you can see this is also simple stuff for a User to maintain.


The validation rule specification is a tad more complex, but is the only portion of SOPS where some limited involvement from IT might be required. The same tokenized SQL or VBA code evaluation can be performed and the use of regular expressions for character and format validation, plus search and replace functionality may require some small amount of assistance from IT support. Figure 11 below illustrates the SOPS field validation specification form.



If you click on the above image to enlarge it, It can be seen that the Discount Percent field (an entry on a product line item row) is validated to be 10% (0.1 value) for this Charity profile. Any other entry results in the User receiving an error message, “All Charity Orders should automatically receive a discount of 10%”. This is quite powerful if you think about it. Only characters 0 to 9, a period (.) and a % are allowed and the minimum and maximum values are 0% and 100% (1) respectively. All of this is quite manageable by a supervisory User and this is pretty much as complicated as it gets in the SOPS prototype.


The basic simplicity of all of these metadata maintenance forms clearly supports the claim that Interaction Profiling enables User maintenance of the metadata for profile definitions, validation rules and BPM processes, with very little need for support from IT.  The next post illustrates the utility of Interaction Profiling for operational BPM requirements, output reporting and ad hoc reporting in particular.


Previous post:  Better BPM – 8    Sales Order Processing Prototype

Next Post:         Better BPM – 10 Prototype Sample Screens and Reports

Leave a Reply

Your email address will not be published. Required fields are marked *