Workfeeds basics

A Workfeed is a crucial component where all information flows within GUBUS converge. Specifically, it is where:

• Data is posted by GUBUS
• Data is scanned by GUBUS formulas
• Users input new relevant information, mark checkboxes as completed, etc.
• Data is read by GUBUS and posted to the next stage
• Data is removed by GUBUS

A Workfeed comprises a header, a formula line holder, a workfeed area for storing data in rows, and a closing row with a 'don't delete' notation, which cannot be deleted under any circumstances.

IMPORTANT! The Workfeed area is dynamic, it can contain any number of rows, from 0 to 1000. Each row in the workfeed area can be inserted, updated, or deleted. Contrary to the STATIC nature of multipanels, a workfeed is DYNAMIC!

Additional comments on the image above:

• The workfeed header is mapped within GUBUS using a flexible config module. You can name columns as you prefer, while the internal names are assigned by the developer.
• You can color the formula line holder in a header color, you can make it as thin as to be invisible, but you are not allowed to delete it.
• You can rename the 'don't delete' instruction to a more user-friendly name, but you cannot delete this row, and you cannot leave the cell with the 'don't delete' notation empty.

The Rule of Workfeed

Like all other components in GUBUS, workfeeds are governed by their own workfeeds_models rule.

We will not delve into the standard components of the workfeed rule. These are automatically created during the GUBUS configuration stage. However, we can enumerate them:

• Reference field - utilized in GUBUS workflow for swift navigation
• Table_id, sheet_name, sheet_id - these are self-explanatory
• Workfeed_model - fields mapped to GUBUS's internal field format

What's more intriguing is the enhanced functionality of workfeeds, which makes GUBUS remarkably efficient.

Mapping on the Server Side

Before we delve into the principles of posting/reading for workfeeds, we should first clarify the term server-side mapping. As you can see in the properties of the workfeeds_models rule, there are two significant fields, named positions_type and positions_watched.

When GUBUS posts some data to a workfeed, it first needs to determine where to post - should a new row be inserted at the top of the workfeed, or should an existing row be updated? If a row is already present, which specific row should we update? In both cases, the usual practice is to make a request, retrieve data, and scan item positions on it. Reality shows that this can take from 0.3 up to 0.8 seconds for each posting, which is quite slow.

Alongside the straightforward mapping of positions, GUBUS boasts a remarkable complex position logic that implements an elegant date-based pre-sorting mechanism.

Principles of Posting

The workfeed is the most adaptable and active area within GUBUS, albeit the most susceptible to errors. Therefore, it necessitates a robust architecture that maintains flexibility while safeguarding against user-induced errors.

The most appealing aspect:

Let's outline the main principles of posting to ensure smooth operation of GUBUS without errors:

• GUBUS ALWAYS posts a new item AT THE TOP of the feed, under the grey formula line holder.
• If complex mapping by date is enabled, GUBUS posts a new item AT THE APPROPRIATE LOCATION.
• The most efficient approach would be to configure GUBUS to automatically eliminate lines from the workfeed.
• If positions are NOT watched on the server-side, you are free to delete/insert as you wish.
• If positions ARE watched, you are generally not permitted to change item positions without issuing an additional reposition command after the change.
• There are numerous automated workfeed maintenance patterns available. Consult your developer and utilize them!

Principles of Reading

Reading workfeeds is a significant challenge that drives many processes in GUBUS. Once a workfeed is read, the GUBUS workfeed module determines which data row is 'done' and should be advanced to the next stage.

A checkbox set to 'true' in a production workfeed signals to GUBUS that this item is complete here, and we can advance the item to the next stage.

A 'Date_today_or_before' in a hotel 'future' workfeed signals GUBUS to move the item to the next stage 'arriving'.

GUBUS has developed a rich set of resolve constants to automate item progression, so you only need to properly configure your GUBUS project.

Resolving Workfeeds

Workfeed progression essentially involves:

• Reading all lines in the workfeed's fluid area
• Checking the 'done' column for equality with the resolve pattern
• Returning an object with all completed lines
• Eliminating rows marked as done from the current workfeed
• Adding new data obtained from the workfeed to the corresponding item

The manner in which data is processed after being read from the workfeed is contingent upon the primary mode of GUBUS:

• If the project operates in transponder mode, simply configure the field next_branch in the workfeeds_models rule, and GUBUS will automatically transfer the information to the destination workfeed without requiring additional configurations.
• If the project operates in item-mode, the future trajectory of the information is managed by the Workflow module, which autonomously determines where items should be eliminated and where they should be posted next.

Interestingly, we frequently utilize next branch automation even in item mode, for instance, to rapidly duplicate 'done' information on production stages. Are you still questioning whether GUBUS is sufficiently robust to accommodate your project?

Now, how does data enter workfeeds? Most commonly, it is through the Multipanel. Explore this further!