Line/Bulk Edits in Flex4 vs Flex5

The Object Graph

The first thing that has to be understood about the difference between Line and Bulk Edits in the two versions of Flex is that Flex4 has what we call "the object graph." While this sounds like a fancy, probably meaningless term, it's actually quite important. What the object graph does is both helpful and detrimental. For instance, when Flex4 loads line items, it also loads the Inventory Item, Resource Type, and Pricing Model (aka Rate) each line uses (among other things). In other words, each of these is held, in memory, at least once.

This is helpful because it means any need we have for them is already met and we don't have to wait to fetch their data; it's just there. So displaying things like names and such is "just done."

Similarly, there are occasions when making a change means changing not only the line item, but possibly another property of another entity. This is where things become detrimental. In some cases, it makes senes to update "everything" affected by a change. It's akin to forwarding your mail; it's a one-stop process to notify the postal service and all of a sudden all your mail is at your new address. That's all fine and dandy until you start getting junk mail forwarded because it has your name on it...

Now, the way Flex5 is designed is, quite literally, the opposite approach. We removed the object graph entirely. Each entity knows only the bare minimum about its "extraneous" properties. In some cases, it doesn't even know it has them because of something called database normalization, but that is out the scope of this article. So a line item no longer "holds" its own Resource Type or Inventory Item. Instead, it holds an identifier to each of those things (maybe, see normalization). We then use targeted lookups to find the right ones. Not only that, if we don't need certain information for a given entity, we typically don't bother pulling it from the database.

For example, on a Financial Document line item, what use are things like the height, width, or SKU of an Inventory Item if you don't have those columns showing? Better still, what use is any setting from a Pricing Model (besides its name) when all we're doing is loading line items? The answer is plain: none. So in Flex5, we don't even lookup data that's useless to the purpose at hand. What this means is that there are more "trips to the database" for information, but in effect, less data is traveling back and forth, less data is being "touched" with each action.

Bulk Edit

So what does this have to do with Bulk Edit? Well, Bulk Edit opens the opportunity to edit a whole slew of properties of more than one line item. Typically, editing line items is a "one line, one property" affair. Single-line changes are "quick and easy," (to a point) even in the object graph world.

However, if you Bulk Edit the Resource Type, Pricing Model, and the Price of a dozen lines, those dozen lines suffer from the bog-down of the object graph. Add to that, the whole document has to be recalculated and the calculation process also has to pull object graph-style data to do it's work... Thanks for the junk mail, Mr. Postman.

Now, not every field in the Bulk Edit window causes this, but many do and it's a lot of work to identify each and every path that's going to suffer from poor performance for any given customer. Additionally, certain other actions, like double-clicking the Price Mute header, initiate a behind-the-scenes Bulk Edit that causes the exact same object graph issues to occur even though Bulk Edit was never touched by the user, including a document recalculation!

As a side note, you might be thinking to yourself, "How the heck does Price Mute do that?! It only affects what's printed in a report!" Yeah. Those are the sort of problems we're fighting in Flex4. It all goes back to the object graph and the chance for performance issues in any given situation.

Flex5

I said it earlier, but I'll say it again: the approach in Flex5 is literally the opposite. Everything we've done has been with the intent of increasing performance and avoid slowness in any given situation for any given customer.

Line items only pull data necessary for display. Line changes and, Bulk Edit in particular, only touch what's being changed. So rather than pull the whole Pricing Model, we're pulling its name and identifier. When you click the cell to change the Pricing Model, we do a quick fetch to find all applicable Pricing Models, but the fetch only grabs their names and identifiers. When you select a new one, we send the line item's identifier, the Pricing Model's identifier, and the identifier for the Pricing Model field. That's it. We have a few lookups to find out which user edited the line and that sort of thing, but never, ever, is the whole Pricing Model or whole Line Item fetched from the database.

Flex4's approach would be to fetch everything about the applicable Pricing Models to populate the cell, then "send" the whole selected Pricing Model back. Obviously, this is overkill.

Additionally, and this is probably the most important part, when we calculate a document, there's absolutely zero object graph stuff happening. We focus the data fetches. We focus the math. We focus what's saved. This means, things like double-clicking the Price Mute header don't cause a document recalculation. It just updates the Price Mute column for all of the line items on the document. That's it. This means that, as a general rule, updating a line item is faster in Flex5. Doing a Bulk Edit is faster in Flex5. And Flex5's document calculation is much faster than Flex4's.

Conclusion

As a team, we can't stress enough the importance that our customers use Flex5 as much as possible in their day-to-day work. We've worked long and hard to get to this day and, at times, it felt like we'd never get here, but the day has arrived. And past. Sure, it's not 100% complete, but we're continually porting features. Yes, it's not 100% perfect, but it's fast and we can fix it when things aren't right. In short, it's time to use Flex5.