Reporting on Frequency of Fragment Usage

[Rob_Dale]

I have a tricky request from our users.  I've been asked to create a report showing which fragments from a certain Doc Comp template are used, the frequency that they are used, and also providing a report on which fragments were used for individual composed letters.

The template in question has 92 possible fragments.  These fragments are selected from an HTML form with 92 check boxes.  Currently, these check boxes are not mapped to keywords, they are only used for selecting the fragments.

I'm really struggling to come up with a viable solution.  The closest I've been able to come up with is update the HTML form to have the check boxes set values in a MIKG.  However, it's not recommended to use MIKG's in Doc Comp.  Having individual keywords doesn't seem like a viable option, as I'd either have to have 92 columns on the report, or create a SQL query to get the values of 92 keywords, and concatenate into a single column.

Has anyone had to do this, or have any suggestions on how to track and report on which Fragments are used?

[Eric_Beavers · Accepted solution]

Is the HTML form an actual Eform Document Type? That is what it sounds like from your description, including the checkboxes being nonkeyword fields. Is this the case?

How many are in the system at this time?

I think Workflow could be a possible solution. Here are few ideas...

For 100-10,000s of these documents, a system task would be fine. For more documents a Unity Scheduler timer would scale much more effectively.

First, Workflow can interact with Non-Keyword fields using Properties.

Take the following Eform example:

Source Code:

To get the value of CheckBox1, I would configure the above action, Set Property Value, (prop name - propOption1) with "From E-Form Field" = c1. I believe the property will store as "on" when the box is checked.

To test this I just call a message box:

so in my client I get a success:

or a null:

Next, you could use the Rule: Check Property Value to see if it matches the above (ex: propOption1 = TRUE).

Then, On True, increment a property (propOption1Count) with Action: Set Property to Expression (propOption1Count = Cint(%VpropOption1Count)+1). With a completed run of a system task or timer, you could then access your propOptionCount with a %VpropOption1Count token and display a message box or send an email report on demand.

I know what you are thinking right now "With 92 separate fields it would be a massive task list", but the logic would be generally a repeat of the same 3 rule/actions listed here. So it would take a few hours to copy and paste, changing the field and property names for each checkbox.

Is there a better approach? As I built this out I started thinking...

Perhaps we can simply the logic and just export to a CSV file with half the logic...then use MS Excel to get the reports.

The logic is easier...2 actions:

The Set multiple props action is new in OnBase18 and very useful here.

The Export to Network Location just needs to be configured as an Index File:

The output =

At this point you can  just use pure ms excel. I added a header row, replaced all instances of "on" with 1, and added a count() function.

[Rob_Dale]

Eric,

Wow, thanks!  That's pretty close.  The one limitation I see from this is that it's running on a task or timer, and since it's a property, it's only available at run time.  I know, the alternative would be 92 keywords, though, which isn't much better.  I'll be discussing with our users.