For specific OMI processing events, matching event procedures in the m_pck_omi_custom CIP package are called. Parameters passed to these CIPs always include the internal primary key of the OMI import job (p_omij_id) and a record variable that holds the complete internal processing state of the OMI main program (and for which the PL/SQL record type is declared in the m_pck_bom_load package specification).
Additionally, node level event procedures get the primary key of the affected node passed (p_ln_id), and the position level procedure gets the position primary key passed (p_lp_id).
The following events are supported by the API:
omi_job_start
Call specification:
PROCEDURE omi_job_start
(p_omij_id IN m_omi_import_jobs.omij_id%TYPE,
p_state IN m_pck_bom_load.state_rec_type);
This procedure is called after an OMI job has started successfully, that is, at that
point in time, the interface table has been populated from the selected data source,
and the OMI main program has been called and has successfully initialized all job
parameters and configuration options. No records from the interface table have been
read or processed yet, however.
omi_job_end
Call specification:
PROCEDURE omi_job_end
(p_omij_id IN m_omi_import_jobs.omij_id%TYPE,
p_state IN m_pck_bom_load.state_rec_type);
This procedure is called after an OMI job has read and processed the last data record
from the interface table; all outstanding BOM transactions have been committed at
that point in time. However, no data from the interface table has been deleted yet.
Also, the job_status and job_status_summary have not yet been updated for the job
record (this update also depends on the outcome of the omi_job_end call).
bom_node_found
Call specification:
PROCEDURE bom_node_found
(p_omij_id IN m_omi_import_jobs.omij_id%TYPE,
p_state IN m_pck_bom_load.state_rec_type,
p_ln_id IN m_list_nodes.ln_id%TYPE);
This procedure is called after an interface table record of type NODE _BEGIN or NODE has been processed and the corresponding BOM node has been found to already exist in the database.
The existence of a BOM node does not necessarily imply that this BOM node was already
present before this OMI job started; it could also mean that this node was created
by this job at some earlier point in time. However, this fact is not tracked by OMI;
internal processing status is tracked only from one interface table record to the
next, from one BOM position assembly to the next, and finally from one BOM node to
the next.
All validations on the node level have been successfully performed at this point in time; also, the internal state as exposed to the CIP by the p_state parameter (see also its type definition in the m_pck_bom_load package specification) contains all necessary variable values to continue processing with the next interface table record in the context of the found BOM node.
bom_node_created
Call specification:
PROCEDURE bom_node_created
(p_omij_id IN m_omi_import_jobs.omij_id%TYPE,
p_state IN m_pck_bom_load.state_rec_type,
p_ln_id IN m_list_nodes.ln_id%TYPE);
This procedure behaves the same way as the bom_node_found procedure as far as the processing state is concerned. The bom_node_created procedure is called, however, if OMI has created the BOM node in question immediately before.
bom_pos_created
Call specification:
PROCEDURE bom_pos_created
(p_omij_id IN m_omi_import_jobs.omij_id%TYPE,
p_state IN m_pck_bom_load.state_rec_type,
p_assy_stack IN m_pck_bom_load.par_lp_tab_type,
p_lp_id IN m_list_pos.lp_id%TYPE);
This procedure is called immediately after OMI has inserted a new position into the
BOM m_list_pos table. For the case in which a BOM assembly is currently being processed,
and this structure is valid (that is, the state variable p_state.s_ill_ass_struc evaluates
to FALSE), the p_assy_stack variable (which is a PL/SQL Index-By table) contains the
assembly structure stack. Its elements may then be accessed by p_state.s_cur_ass_lvl
for the current assembly level and p_state.s_prev_ass_lvl for the previous (that is,
the parent position) assembly level.
Please be aware that this procedure is called once for each position created; you should keep the code you implement here as compact and fast as possible, because otherwise, the overall OMI import performance will be seriously affected.