Clases necesarias para el desarrollo de plugins

Persistencia de datos

Clase	MPluginPO
Funcionalidad	Logica de negocios en persistencia
Definición	Todo plugin que comprenda logica de persistencia debe extender de esta clase. Se deberán redefinir los métodos que sean necesarios (preBeforeSave, postBeforeSave, etc).
Convenciones	Las mismas que para PO: Se relaciona el nombre de la tabla con la clase M correspondiente, priorizando el package del plugin. Los métodos a implementar contienen los prefijos pre o post (por ejemplo preBeforeSave, preAfterSave, postBeforeSave, etc.)
Retorno	Cada método deberá retornar una instancia de MPluginStatusPO, indicando: 1) El estado próximo de la ejecución a realizar (continueStatus) 2) En caso de error, indicar el mismo a fin de informar al usuario

Clase	MPluginStatusPO
Funcionalidad	Estado de retorno para persistencia objeto-relacional.
Definición	El core lee la información devuelta por los metodos PO redefinidos en las subclases de MPluginPO. En función del continueStatus, el core: 1) Detendrá la ejecución de persistencia (STATE_FALSE), 2) Salteará el metodo principal del core (override completo del metodo de persistencia del core) (STATE_TRUE_AND_SKIP), 3) Continuará la ejecución del metodo principal (el plugin es un agregado funcional al metodo principal del core) (STATE_TRUE_AND_CONTINUE)

Clase	MPluginDocAction
Funcionalidad	Logica de Documentos
Definición	Todo plugin que comprenda logica de documentos deberá extender esta clase. Se deberán redefinir los métodos que sean necesarios (preCompleteIt, postComplete, etc).
Convenciones	Las mismas que para PO: Se relaciona el nombre de la tabla con la clase M correspondiente, priorizando el package del plugin. Los metodos a implementar deberán tener los prefijos pre o post según corresponda (ejemplo: preCompleteIt, postCompleteIt, etc.)
Retorno	Cada método deberá retornar un MPluginStatusDocAction, indicando: 1) El estado próximo de la ejecución a realizar (continueStatus) 2) El m_processMsg 3) El docStatus

Clase	MPluginStatusDocAction
Funcionalidad	Estado de retorno para logica de documentos
Definición	El core lee la información devuelta por los metodos redefinidos en las subclases de MPluginDocAction. En función del continueStatus, el core: Detendrá la ejecución de logica de documentos (STATE_FALSE), Salteará el metodo principal del core (override completo del metodo de logica de documentos del core) (STATE_TRUE_AND_SKIP), Continuará la ejecución del metodo principal (plugin es un agregado funcional al metodo principal del core) (STATE_TRUE_AND_CONTINUE)

Clase	CalloutPluginEngine
Funcionalidad	Implementacion o redefinición de callouts
Definición	Todo plugin que comprenda logica de callouts deberá extender esta clase.
Convenciones	Se deberán implementar los metodos respetando la siguiente convención: La clase deberá tener igual nombre que la Tabla, anteponiendo la palabra Callout. El metodo deberá tener igual nombre que la Columna, pero anteponiendo un prefijo “pre” o “post”. Por ejemplo: CalloutInvoiceLine.preM_Product_ID()
Retorno	Cada método deberá retornar un MPluginStatusCallout, indicando: 1) El estado próximo de la ejecución a realizar (continueStatus) 2) En caso de error, indicar el mismo a fin de informar al usuario

Clase	MPluginStatusCallout
Funcionalidad	Estado de retorno para logica de callouts
Definición	El core lee la información devuelta por los metodos redefinidos en las subclases de MPluginDocAction. En función del continueStatus, el core: Detendrá la ejecución del callout (STATE_FALSE), Salteará el metodo principal del core (override completo del metodo o métodos de callouts especificados en el campo de AD_Table) (STATE_TRUE_AND_SKIP), Continuará la ejecución del metodo principal (plugin es un agregado funcional al metodo principal del core) (STATE_TRUE_AND_CONTINUE)

Funcionalidad	Redefinición de procesos
Definición	Un plugin deberá redefinir un proceso por completo, pudiendo extender de SvrProcess o del proceso que está redefiniendo
Convenciones	Será necesario implementarlo dentro del package de plugins correspondiente, con el mismo nombre de clase que la definida en AD_Process
Retorno	Los procesos redefinidos no preveen una politica de ContinueStatus, ya que no tiene sentido. Para dos plugins que redefinen un mismo proceso, se ejecutará el plugin con menor CoreLevel.

Clase	InfoGeneralPlugin entre otras
Funcionalidad	Redefinición de ventanas Info
Definición	Todo plugin que deba redefinir una ventana Info, deberá redefinir alguna de las clases detalladas en las covenciones, según esté redefiniendo una de las Info convencionales (InfoProduct, InfoBPartner, InfoInvoice, etc.) o creando una Info genérica (para cualquier otra tabla).
Convenciones	Para redefinir una Info convencional, se debe implementar dentro del package correspondiente con el mismo nombre de la clase que se está redefiniendo. Esta nueva clase podrá extender tanto de la clase redefinida como directamente de InfoOrder, según sea necesario. Para crear una Info genérica, será necesario respetar la siguiente convención: Si la tabla a visualizar en la ventana Info se llama C_AllocationHdr, la clase deberá llamarse InfoAllocationHdr y deberá extender InfoGeneralPlugin a fin de respetar el constructor que invoca el engine de plugins.

Tambien incluye soporte.