Working with Master File Master Business Functions
Master business functions (MBFs) enable calling programs to process certain predefined transactions. An MBF encapsulates the required logic, enforces data integrity, and insulates the calling programs from the database structures. Use MBFs for these reasons:
To create reusable, application-specific code.
To reduce duplicated code.
To ensure that hookup is consistent.
To support interoperability models.
To enable processing to be distributed through OCM.
To design event-driven architecture.
MBFs are typically used for multiline business transactions such as journal entries or purchase orders. However, certain master files also require MBF support due to their complexity, importance, or maintenance requirements from external parties. The requirements for maintaining master files are different from those for multiline business transactions.
Generally, master file MBFs are much simpler than multiline business transaction MBFs. Transaction MBFs are specific to a program, while master file MBFs access a table multiple times.
For interoperability, master file MBFs can be used instead of table I/O. This enables you to perform updates to related tables using the business function instead of table event rules. Multiple records are not used; instead, all edits and actions are performed with one call.
In their basic form, master file MBFs have these characteristics:
Characteristic |
Description |
|---|---|
Single call |
Generally, you can make one call to an MBF to edit, add, update, or delete a master file record. An edit-only option is available also. |
Single data structure |
The fields required to make the request and provide all the necessary values are in one data structure. The data fields should correspond directly with columns in the associated master file. |
No cache |
Because each master file record is independent of the others, caching is unnecessary. The information provided with each call and the current condition of the database provides all of the information that the MBF needs to perform the requested function. |
Normal error handling |
As with other MBFs, master file MBFs must be capable of executing both in interactive and batch environments. Therefore, the calling program must determine the delivery mechanism of the errors. |
Inquiry feature |
To enable external systems to be insulated from the JD Edwards EnterpriseOne database, an inquiry option is included. This enables an external system to use the same interface to access descriptive information about a master file key as it uses to maintain it. |
Effect on applications |
For JD Edwards EnterpriseOne applications, the effect of implementing a master file MBF should be minimal. Consider and follow several standards before implementing a master file MBF. |
Master file applications use the system to process all I/O for find/browse forms. This enables you to use all of the search capabilities of the software.
You should design all master file applications so that all fix/inspect forms are independent of each other. Each fix/inspect form can use the system to fetch the record, and all edits and updates occur using the master file MBF. This independent design has these major benefits:
It organizes the application in a way that simplifies edits involving dependent fields across multiple forms.
It enables consistent implementation of modeless processing for all master file applications and all forms within these applications.
Certain circumstances might justify deviation from this simple model. These circumstances are:
Extremely large file formats
When the number of columns in the master file plus the required control fields in the call data structure exceed technical limitations for data structures, the MBF can be split. You can split the MBF into one MBF that handles base data and performs all adds and deletes, and one or more MBFs that enable the calling program to update additional data when the base data has been established. In this case, it is usually logical to split it, regardless of the technical limitation. For example, assuming that the customer master file exceeded the data structure limitation, you would use these two MBFs to process the file:
F0301ProcessMasterData
F0301ProcessBillingData
In this example, the F0301ProcessMasterData function processes the base data, and the F0301ProcessBillingData function updates additional data.
Subordinate detail files
Information can exist in addition to the primary master file that has been normalized to enable for a one-to-many relationship. Designing the Master File MBF strictly on the basis of how the database is designed translates into three calls. Including at least one occurrence of a detail relationship in the data structure of a Master File MBF is valid. This inclusion enables users to establish reasonably complete master file information using a simple interface to meet simple needs. Street addresses and phone numbers within Address Book are a good example. Customers expect that they can create an address book record by calling a simple address book API with basic identifying information, the street address, and a phone number.