Working with parameters

There are two ways in which your trigger processing procedure can use parameters for the original procedure:

It can use no parameters, thereby ignoring values from the original procedure. This is the recommended method of using a procedure trigger.
It can use the same parameters as the original procedure. However, the parameters in the trigger processing procedure must match the parameter list of the original procedure script.

Ignoring parameters

When using procedure triggers, we strongly recommend that you do not alter parameters passed from the original script. Using this method, a third-party developer’s procedure trigger simply runs when the specified Microsoft Dynamics GP procedure is called. The values of a Microsoft Dynamics GP procedure’s parameters are difficult to determine unless you can accurately predict where and how the procedure will be called. Furthermore, changing parameter values in a Microsoft Dynamics GP procedure is also more likely to unexpectedly alter the results of other procedures called in a Microsoft Dynamics GP process.

Example 2: Ignoring parameters

This example runs when a user attempts to log into the accounting system. It checks whether the user registered the Contact History application, and if not, displays a message.

{Name: Startup}
local integer l_result;

l_result = Trigger_RegisterProcedure(script System_Login, TRIGGER_AFTER_ORIGINAL, script IG_Check_Login);
if l_result <> SY_NOERR then
	warning "Procedure trigger registration failed";
end if;

This trigger processing procedure runs when the System_Login procedure is called. This procedure runs when the user initially logs into Microsoft Dynamics GP.

{Name: IG_Check_Login}

get first table IG_Setup by number 1;
if 'Company ID' of globals = -1 and not Registered of table  IG_Setup then
	{The user is logging into the sample company., but hasn't
	 registered the application yet.}
	warning "The Customer Contacts application is enabled for the sample company only. Be sure to register sample for all other companies.";
elseif 'Company ID' of globals <> -1 and not Registered of  table IG_Setup then
	{The user is logging into a company other than the sample,
	 and hasn't registered the application yet.}
	warning "The sample application won't be enabled for this company until you register it using the Sample Setup  window.";
end if;

Using original parameters

If you choose to use the parameter values from the original procedure, the trigger processing procedure must match exactly the type (in, out or inout), order and data type of the parameters in the original procedure. If the parameter list doesn’t match, the registration for the processing procedure will fail.

We recommend that you avoid changing parameter values in Microsoft Dynamics GP procedures. The values of a procedure’s parameters are difficult to determine unless you can accurately predict where and how the Microsoft Dynamics GP procedures will be called.

There are additional considerations you should take into account when working with parameters from an original procedure, depending on whether it’s called in the background or the foreground. Note that the differences are based on how the procedure was called (using either the call or call background statements), not how it’s actually running.

Scenario 1 – Background keyword not included

In this scenario, a script calls the Microsoft Dynamics GP procedure for which triggers have been registered. The call does not include the background keyword. The following table shows how the original procedure and the trigger processing procedures run.

Step	Procedure call	Description
1	call OrigProc, parameters	A script calls the original procedure for which triggers have been registered. A set of parameters is passed to the procedure. The procedure triggers and runs in the following manner:
2	call PreTriggerProc, parameters	The pre trigger processing procedure runs first.
3	call OrigProc, parameters	Next, the original procedure runs. The parameters from the pre trigger processing procedure are passed to the original procedure. Any changes the pre trigger processing procedure made to the parameters will be seen in the original procedure.
4	call PostTriggerProc, parameters	Then, the post trigger processing procedure runs. The parameters from the original procedure are passed to the post trigger processing procedure. Any additional changes the original procedure made to the parameters will be seen in the post trigger processing procedure.
5		Finally, the resulting parameter set is returned to the original calling script.

Scenario 2 – Background keyword included

In this scenario, a script calls the Microsoft Dynamics GP procedure for which triggers have been registered. The call includes the background keyword. A set of parameters is passed to the procedure. The following table shows how the original procedure and trigger processing procedures run.

Step	Procedure call	Description
1	call background OrigProc, parameters	A script calls the original procedure for which triggers have been registered. The call includes the background keyword. A set of parameters is passed to the procedure. The procedure triggers and runs in the following manner:
2	call background PreTriggerProc, parameters_copy	The pre trigger processing procedure runs first. It gets its own copy of the roiginal set of parameters.
3	call background OrigProc, parameters_copy	Next, the original procedure runs. It also gets its own copy of the original set of parameters.
4	call background PostTriggerProc, parameters_copy	Then, the post trigger processing procedure runs. Like the other scripts, it gets its own copy of the original set of parameters.

Example 3: Using parameters

This example logs master posting activity to an activity table. The trigger processing procedure responds to the SY_Master_Post procedure, which posts all batches of a given batch source.

{Name: Startup}
local integer l_result;

l_result = Trigger_RegisterProcedure(script SY_Master_Post, TRIGGER_AFTER_ORIGINAL, script IG_Log_Posting_Activity);
if l_result <> SY_NOERR then
	warning "Procedure trigger registration failed";
end if;

This trigger processing procedure uses the same parameters as the SY_Master_Post procedure. It uses the in parameters to set values in a log table used for tracking posting activity.

{Name: IG_Log_Posting_Activity}
in string batch_source;
in integer source_window;
in 'Print Report Flag Array' l_report;
in 'Print To Printer Array' l_printer;
in 'Print To Screen Array' l_screen;
in 'Export File Type Array' export_file_type;
in 'File Export Name Array' export_file_name;

set 'Batch Source' of table IG_Posting_Activity to batch_source;
set 'Posting Time' of table IG_Posting_Activity to systime();
set 'Posting Date' of table IG_Posting_Activity to sysdate();
if source_window = 4 then
	{The posting occurred from the Master Posting window.}
	set 'IG Source Window' of table IG_Posting_Activity to "Master Posting";
else
	{The posting occurred from the Series Post window.}
	set 'IG Source Window' of table IG_Posting_Activity to "Series Posting";
end if;
save table IG_Posting_Activity;