|
I'm trying to generate messages related to required fields missing at my website - the logic that checks for this condition is in an ART subset rule, and is invoked from my website using field level exits. I do not get the ART messages back from the call to ExecuteRule, even though the ART rule logic indicates that the message should be returned. I've tested this using the Phoenix Web Services test application, and my ART messages are getting returned by the ExecuteRule web service call. What can I look at to help debug/diagnose this problem? Any suggestions for what might be going on here? Thanks! 
|
|
The JavaScript that handles the ExecuteRule call has a few predefined IDs that it places messages in. These IDs are hard-coded and cannot currently be changed, although plans are in the works to allow such customization. The IDs are as follows: "message_div" - General PortalServer messages will be placed here. "artMessage_div" - ART messages will be placed here. Simply place DIV or SPAN elements on your website with the appropriate IDs for the messages to appear.
|
|
Thanks Patrick - I'm already using those IDs, but still not consistently getting my ART messages back. This behavior appears intermittently, could there be a timing issue somewhere? What tools can I use to try to Debug what's going on? Joe
|
|
Check your logs for the AMS Phoenix Link WebServices, certain error and warning messages may be getting logged there. Additionally you can set a breakpoint in the showNewMarkup of the executerules.js file using the FireFox plugin "firebug". Inspecting the markup object should reveal if the messages are being provided to your website. Because PortalServer does not usually give you access to the XML that will be passes to Phoenix Link it is possible that the data differs slightly from that contained in the test case you have tested with the Phoenix Link Test App and the conditions that trigger the ART message might not actually be satisfied. Make sure all relevant fields that are necessary to trigger the message are on the template in question so that you can be absolutely sure that the message is really being triggered by PortalServer.
|
