WKS: On Documents with many items and the UI-Performance in the item view

In TM we have customers of all sizes and document structures, this includes documents with a lot of items. I mean, in the 4-5 digits space…

There are some important settings affecting the UI performance in such a scenario, and this is the focus of this posting. Specifically I address here Ocean and Air Booking scenarios where a LOT of items coming from freight units are assigned to few container items. But some of the settings can also be applied to other scenarios, of course.

The bread & butter item view is the All Items view. This view basically shows all items expanded and including the assignment of the source documents. But where does this come from?

The answer is the hierarchy type customizing (TA code /SCMTMS/C_OH). In there, there is quite some config, let’s have a look at the All Items view, which has the technical Name ITEM:

In the hierarchy it is defined, that this view can be used as item detail in the Items section of TOR based documents (defined in the so called Consumer) and that is is not limited to specific mode of transports. I intentionally do not include all columns of this view here, we come back to this topic later 🙂

The other important setting is the definition of the hierarchy Levels to be shown and expanded in the hierarchy, to define this select the entry and press the “Hierarchy Levels” folder on the left:

Basically all kind of items and groupings (Like the ERP document numbers where we show the e.g. delivery document as a parent of the items coming from the delivery) are defined in here as visible and expanded. As set, this is the default and we want to show as much information as possible.

Ok, we made it till here and so far nothing about how to optimize the performance, we are close!

In scenarios with many items one of the key performance consumers is the determination of the properties of the field of the items, many items, many fields, that makes a lot of properties. So the key is to reduce this. And here is (finally ;-)) how.

First dimension is the number of items to be available in the hierarchy:

If e.g. the product items are not really required to be shown, they can just be deactivated by removing the flag in the “Show Level” column. And there is a special trick (not available in all releases, so please check yours): With the column “Show Topmost Item” you can fine tune the behavior of the requirement items:The idea for this flag is, that only the topmost layer of a item category should be shown.

This is specifically relevant for deep packaging structures, with this setting you can define that only the outermost hierarchy level is shown on the UI. And you can choose if this applies per requirement document or for the complete document, e.g. in case of packages defined other layers, e.g. a package unit or you have package items in the Freight Unit, but they are also packaged in the freight order again.

With that, the number of items which are loaded can be significantly reduced already. But there is more. The flag “Expanded” defines, if a certain level is by default expanded or collapsed. And the good thing: Thanks to some TBI/Dragos magic, the properties for the levels which are hidden are not read. Great! So, if you use a hierarchy like the following one, by default only the container item is visible and  the packages and products are only shown when they are topmost:

So, in our ocean example the properties would be determined only for the container item (and there might only be one)! This makes a ton of a difference!

And, there is still more, talking about the way the properties are are defined / read:

When defining the hierarchy type, there is the “Editability”-Field:

Here you can define, if for that view the default is read only. This of course simplifies the determination of properties a lot, again. If it is active, then everything in the view is read only, unless you select a line and press the Edit button in the item view:

OK, that´s it, actually. But there is one more question: Where does the default view you see when entering the document actually come from? The answer is in the WebDynpro Configuration: In the wire definition for the items, there is the magic parameter:

The example is from an ocean booking, where the item UIBB is called //WDCC_BSEA_ITM, you find similar patterns in the other UIs.

So, in here, currently the ALL Items config is used (which my change in the future…).

So, what are your options now in case you want to use a different item hierarchy customizing?

Here we go:

1. You can adapt the hierarchy customizing of the delivered types, like “All Items”. This affects then all UI configs where this hierarchy is used. It might also get overridden when importing the standard customizing after an upgrade or so. So it´s simple, but also a bit dangerous.
2. In the document types, a custom Web Dynpro Config can be defined. In your config, you can change the wire definition
3. Finally: You can define a customization of the delivery component config, where you adapt the wire parameter.

To illustrate the effects of the different switches we have some numbers (your mileage may vary, as the example is using a document with a certain item structure and a given hardware etc.):

Thanks to @Balazs for the numbers!

With that, I hope this give some more clarity and explains the options you have when working with a lot of items in the hierarchies…