Chapter 3

Functions Required for All Modules

Introduction

The functions described in this chapter are required for every module.

Required Module Functions

Module_Type

Returns the module type.
The following module types are available in Miva Merchant:

Module Type	Description
BATCHREPORT	Batch Order Reporting
CURRENCY	Currency
EXPORT	Data Export
FULFILLMENT	Fulfillment
IMPORT	Data Import
LOG	Logging
PAYMENT	Payment Processing
SHIPPING	Shipping
STOREUTIL	Store Utility
SYSTEM	System Extension
TAX	Tax
UI	User Interface
STOREWIZARD	Wizard in a Store
WIZARD	Wizard at Domain

The type must be in all caps and can only contain one of the valid module types. If the type is not correct, an error message will occur when the module is installed.

Module_Code

Returns a unique identifier that defines the module. If there is another module that already contains this identifier, an error message will occur when the module is installed.

Any internal functions that are developed for the module should use this code as the first part of the function name. For example, if the unique identifier is "Exmpl" then, the name of an internal function should be "Exmpl_ChangeModule."

Module_Name

Returns the text value of the name given the module by the developer.

Module_Provider

Returns the developer name or more specially the party who is responsible for the module. If a module were developed by a third-party who then sells the product to Miva Corporation, Miva would then be responsible for any maintenance of the module and would be the key contact for that module.

Module_API_Version

Returns the version of Miva Merchant that the module was developed for. If a module is developed for Miva Merchant version 2.0 and it is loaded into a Miva Merchant 2.1 API environment, the API would allow the module to run, not requiring or using any of the new functionality. This allows modules to have backward compatibility.

Module_Version

Returns the version of the module and the information is displayed on the module information screen. This is very helpful if there are more than one version of the module available. The developer can then ask the user what version is being used if there are questions regarding the module.

Module_Is_Wizardable

Returns a `1' to indicate that the module has wizard capabilities. A wizard cannot successfully call a module that is not wizardable. See "Wizard Module Functions" on page 33 that are required when Module_Is_Wizardable returns a non-zero value.

Additionally, refer to "Wizard Functions Used in Subordinate Modules" on page 35.

Module_Install

Called when a module is added to the Miva Merchant domain to run within the domain. This function is used only when the module performs some functionality or provides data that is shared between all of the stores in a domain.

The function creates any databases and subdirectories that may be required. It also creates any error messages that are required.

Module_Upgrade

Upgrades modules that run within the Miva Merchant domain.

It defines what action must be taken to upgrade from one version to another. If the module has more than two versions that could be actively used, the action for each upgrade should be given. If there are four version in use (v1.0, v1.1, v2.0 and v3.0), the code should be written transparently.

Therefore, if a person is upgrading from v1.0 to v3.0 the code should first upgrade to v1.1 then to v2.0 and finally to v3.0.

A simple example would be if the fields used in the module have changed somehow with each new version. There may be fields in a the new version that are were not in an older version. If this is the case, the databases would have to be each upgraded and the data written into the new database from the old. If a person were upgrading from v1.1 to v3.0 this process would have to be done twice.

Miva Merchant will not call this function if the version number of the module being installed is less than the one installed.

Module_Upgrade_Store

Upgrades the module for a particular store. It alters the databases and subdirectories that apply to a specific store.

Module_Uninstall

Contains the code necessary to reverse what was done during Module_Install. Any action that is taken in Module_Install should be reversed in this function. It could be deleting a database or subdirectory or deleting a user from the licensed-user database.

Module_Install_Store

Called when a module is assigned to a store. The function creates any databases and subdirectories that may be required by the module for each store location. It also creates any error messages that are required.

Module_Uninstall_Store

Opposite of the Module_Install_Store function. Every action that takes place in the install function should be reversed in this module. All databases and directories that have been established should be deleted. The store should be taken out of the "installed stores" database. Any other functions that were required to establish the store must be reversed and cleaned up.

Module_Pack_Store

Packs and re-indexes the store databases that are used by the module.

Module_Is_Provisionable

Returns a 1 when module is provisionable, which requires Module_Provision function. Otherwise, returns 0.

Module_Provision

PARAMETERS = "version, store_code, delimiter, data"

Required when Module_Is_Provisionable returns a non-zero value.

Module_Pack_Domain (4.1x)

Packs and re-indexes the domain databases that are used by the module.

The section "Required Configuration Functions" on pageÝ10 in the Chapter "Configuration Functions" contains an explanation of the Tabs, Content, Validate, and Update functions.

Module_Domain_Tabs

Defines the tabs for the domain.

Module_Domain_Content

PARAMETERS = "tab, load_fields"

Defines and displays the text for the domain's tabs.

Module_Domain_Validate

Validates the domain field values.

Module_Domain_Update

Updates the domain field values.