Group Design and Size

Because your interface program builds groups for conversion and ongoing interface purposes, you must take several things into consideration in terms of group size and group structure. The most important consideration is how the group control and status information enables the operator to tie back to the source system for either conversion or ongoing interface balancing.

You use two fields on PS_GROUP_CONTROL to categorize groups: Origin and Group Type. Origin typically refers back to the source system, and Group Type represents the type of activity. Possible uses of these fields include:

  • Establishing different origins for conversion groups from ongoing billing interface groups.

  • Establishing different group types for conversion groups.

  • Establishing a different group type for open and closed items and limiting a group to containing either open or closed items.

  • When converting open and closed items with the intent of establishing history, creating one group for each month of activity that you convert and using the Group ID field to indicate the time frame.

No optimal size exist for a group in terms of how many pending items the group should contain. After balancing back to the source system is considered, other issues include:

  • Slight processing overhead that is associated with a group, meaning that fewer groups with more pending items in each will then process more quickly.

  • An online environment that contains some restrictions for the number of rows that can appear on a page.

    You can use two page formats to view external groups online. For the first page type, you view items in a scroll and scroll up or down to see all the items. In this type of page group, the number of pending items that you can display without receiving a page processor error is between 50 and 100, depending on how many pending distribution rows exist.

    For the second type of page, one pending item appears at a time. For example, PeopleTools limits the number of pending items in the list to 255 for some lists.

    Although you may think from this example that a group should never contain more than 255 pending items, a larger group works quite well for several reasons. For example, you have a group containing 5,000 pending items. The first time the group is posted, none of the 5,000 pending items are posted. Each of the items is unlikely to have a unique error. When you bring up the first 255 rows on an error correction page, you may discover that most of them have the same error, such as an invalid payment term. You correct the value on the setup table and post the group again. Then you find that most of the pending items are posted and you have only a few remaining rows to correct.

    After you work out setup-related conversion issues and have your ongoing interface established, the number of errors that occur, if any, should be minimal. To facilitate this process, you will find helpful the task of first developing test conversion and interface groups that contain a sample of the data that you process. This helps to eliminate setup issues and enables you to process the group size for conversion and ongoing interfaces that best suit business control and balancing.