Light Business Objects
Sometimes it is possible to create a smaller schema that only accesses the objects that are needed for a particularly performance-instensive process. This can be particularly important if there are many child collections that are referenced by a particular business object (BO). When a child collection on the maintenance object (MO) is not mapped, the application does not issue a read. While a large BO with many collections might be acceptable for online transactions, a process used in a batch could benefit by a smaller subset of elements. These smaller BOs are referred to as Light or "Lite" BOs.
When any XML-mapped field is referenced, the application must parse the XML's columns data. Depending on how much data is mapped, there could be some minor savings gained by avoiding the XML data since it will not need to be parsed.
Here is an example of a very large BO:

<schema fwRel="2">
<mainSection type="group" mdField="C1_TAXFORM_MAIN_LBL"/>
<selectTaxFormLabel type="group" mdField="C1_SELECT_TAXFORM_LBL"/>
<taxFormId mapField="TAX_FORM_ID" isPrimeKey="true" fkRef="C1-TXFRM"/>
<formType mapField="FORM_TYPE_CD" fkRef="C1-FRMTY"/>
<bo mapField="BUS_OBJ_CD" fkRef="F1-BUSOB" suppress="true"/>
<boStatus mapField="BO_STATUS_CD"/>
<statusUpdateDateTime mapField="STATUS_UPD_DTTM" suppress="true"/>
<totalAmountDueOverpaid mapField="C1_TOTAL_OWED_OVERPAID"/>
<remittanceAmount mapField="C1_FORM_PYMNT_AMT"/>
<formSource mapField="C1_FORM_SRCE_CD" fkRef="C1-FRMSC"/>
<formDetailsInfoSection type="group" mdField="C1_ITF_FORM_DTLS_INFO"/>
<demographicInfoSection type="group" mdField="C1_TF_DEMO_INFO_LBL"/>
<taxpayerDemographicInformation type="group">
<includeDA name="C1-TaxpayerDemoInfo"/>
</taxpayerDemographicInformation>
<lineItemsInfoSection type="group" mdField="C1_TF_LINE_ITEMS_LBL"/>
<obligationId mapField="SA_ID" fkRef="SA"/>
<receiveDate mapField="RECV_DT" required="true"/>
<taxFormFilingType mapField="TAX_FORM_FILING_TYPE_FLG" default="C1OR" required="true"/>
<formBatchHeaderId mapField="FORM_BATCH_HDR_ID" fkRef="C1-FBHDR"/>
<documentLocator mapField="DOC_LOC_NBR"/>
<adjustReason dataType="lookup" mdField="C1_TXF_ADJRSN_FLG" mapXML="BO_DATA_AREA"/>
<transferReason dataType="lookup" mdField="C1_TXF_TFRRSN_FLG" mapXML="BO_DATA_AREA"/>
<reverseReason dataType="lookup" mdField="C1_TXF_RVSRSN_FLG" mapXML="BO_DATA_AREA"/>
<cancelReason dataType="lookup" mdField="C1_TXF_CANRSN_FLG" mapXML="BO_DATA_AREA"/>
<issuesSection type="group" mdField="C1_TF_ISSUES_LBL"/>
<suspenseIssueList type="group" mapXML="BO_DATA_AREA">
<includeDA name="C1-IssuesList"/>
</suspenseIssueList>
<waitingForInfoIssueList type="group" mapXML="BO_DATA_AREA">
<includeDA name="C1-IssuesList"/>
</waitingForInfoIssueList>
<taxpayerPersonID fkRef="PER" mdField="PER_ID" mapXML="BO_DATA_AREA"/>
<account fkRef="ACCT" mdField="ACCT_ID" mapXML="BO_DATA_AREA"/>
<taxRole fkRef="C1-TXRL" mdField="TAX_ROLE_ID" mapXML="BO_DATA_AREA"/>
<transferAdjustSection type="group" mdField="C1_TF_TRANSFER_ADJUST"/>
<adjustedFromForm fkRef="C1-TXFRM" mapXML="BO_DATA_AREA" mdField="C1_TF_ADJUSTED_FROM"/>
<transferredFromForm fkRef="C1-TXFRM" mapXML="BO_DATA_AREA" mdField="C1_TF_TRANSFERRED_FROM"/>
<adjustedToForm fkRef="C1-TXFRM" mapXML="BO_DATA_AREA" mdField="C1_TF_ADJUSTED_TO"/>
<transferredToForm fkRef="C1-TXFRM" mapXML="BO_DATA_AREA" mdField="C1_TF_TRANSFERRED_TO"/>
<version mapField="VERSION" suppress="true"/>
</schema>
This performance-sensitive process only required a subset of the BO, so the following light BO was created:

<schema fwRel="2">
<taxFormId mapField="TAX_FORM_ID" isPrimeKey="true" fkRef="C1-TXFRM"/>
<formType mapField="FORM_TYPE_CD" fkRef="C1-FRMTY"/>
<bo mapField="BUS_OBJ_CD" fkRef="F1-BUSOB" suppress="true" required="true"/>
<boStatus mapField="BO_STATUS_CD"/>
<receiveDate mapField="RECV_DT"/>
<formChangeReasons type="group" mapXML="BO_DATA_AREA">
<formChangeReasonsList type="list">
<formChangeReason mdField="FORM_CHG_RSN_CD" isPrimeKey="true" fkRef="C1-FRCHR"/>
</formChangeReasonsList>
</formChangeReasons>
<formChangeComments mdField="COMMENTS" mapXML="BO_DATA_AREA"/>
<version mapField="VERSION" suppress="true"/>
</schema>
Benefits of Light BOs
• Not mapping unneeded child collections removes the need to read the child table from the database.
• The "read" benefits extend to BO updates as well, though in a minor way. The light BO would be used for the read when finishing an update. However, this benefit may be reduced by the availability of the updateWithoutRead action, which would do the update with whatever BO was presented, and then not do a read at the end. This would achieve an optimization as well as the light BO update.
• XML document size reduction. There are performance penalties when transmitting and parsing large XML documents.
Disadvantage of Light BOs
While this is not really a disadvantage of the concept, creating additional BOs results in more objects to maintain.
Tips and Conventions
• The light BO Code ends with "Light" or "Lite" and description ends with "Light". The rest of the code and description should follow the normal BO naming standard.
• Instance Control is set to "Do not allow new instances".
• Each MO has one parent light BO. The parent light BO schema would contain just the first level elements and no collections.
• Each "child" light BO for the MO has the parent light BO as its parent. This is important for the BO Hierarchy dashboard zone.
• When to update an existing light BO versus creating a new light BO: Generally reuse and update an existing light BO if the level or "collection level" of the element to add is in an existing light BO. A new light BO is warranted if a new "collection level" is needed. If multiple levels and many elements are needed, you may consider reading the actual BO instead of the light BO.