Hi all -- looking for a "sniff test" on the following if anyone would care to offer feedback.
We recently got creative with TNEW's "Local Procedure Execution" customization path to create an "entry point" that would elegantly handle promo code and validation points when the user had an existing session. It works great, except that if extra URL arguments are appended when hitting the entry point, the WP_LOCAL_PROCEDURE errors out because it can't find those same parameters in the target procedure. This means when we link to this entry point from within an email from mail2, for example, the extra analytics arguments that are added cause the procedure to error out.
I've worked around this by modifying WP_LOCAL_PROCEDURE to, instead of erroring out when unknown parameters are encountered, to simply remove those parameters before sending them to the target procedure.
The only way I can conceive of this impacting other functionality would be if one of the applications (TNEW or mail2) is actually _relying_ on hitting that particular error. I certainly wouldn't expect that to be the case, but you never know. Does this sound at all reasonable?
Nick,
The Network considers the WP_LOCAL_PROCEDURE method to be functioning as intended in that it will raise an error if more arguments are supplied than are defined for the local procedure being referenced. As such, and as is always our policy, we do not endorse modifications to standard tables, views or stored procedures.
Our recommendation would be to open a support ticket with Web Products support to investigate the business case of what you are doing in order to find a solution that would suffice without changing the standard procedure. If there are varying scenarios where you might have differing numbers of parameters, perhaps you could have multiple validation points to handle these use cases (one for Mail2, one for sessions transferred from the www site, etc.). But again, this is something that the Web Products team can best assist you with via TASK.
Thanks Gregg,
You're right that the "correct" solution to this problem does not lie in modifying impresario sprocs, but like many things this is not a "quick fix". I'll still open the ticket, but I still need to plan to live with this for the foreseeable future.