Sample Scenario 11: Cross-site Event Firing - Adding a Message to another Site's Inbox

This scenario illustrates the general requirements that are used to set up cross-site event firing. The example adds a message to another site’s Inbox form.

  • A GenericNotify event handler is available in every target site. You can fire this event to perform the remote work.

    This event has one handler with one action that performs a Notify by using event parameters for To, Subject, Category, and Body.

  • A stored procedure called dbo.FireGenericNotifySp is available in every target site. You can use this stored procedure to fire the application event. This stored procedure accepts the T-SQL parameters (@To, @Subject, @Category, and @Body) and fires the GenericNotify event that passes in the information that the application event requires.

    Note: You can do the same thing by using a hand-coded IDO Method that calls Mongoose.EventSystem.EventHandlers.FireApplicationEvent() in case the event requires IDO-level actions. However, for this scenario, the stored procedure is easier to perform.

  • To add a message to another site's inbox, your event handler includes a Dispatch IDO Request action that provides these parameters:

    Parameter Description
    URL( )

    URL of an IDO Request Service that serves the target site

    The sample value is http://MyUtilityServer/IDORequestService/RequestService.aspx.
    CONFIGNAME( )
    Name of a configuration whose application database contains the target site.
    Note: Mongoose requires a configuration that is named after each site, so you can use the site name here.

    The sample value is E(SiteId).

    IDOREQUEST( )

    Invoke “SP!” (or the name of an IDO) plus the name of the stored procedure (in this case FireGenericNotifySp) that passes in the event parameters as method parameters.

    The sample value (shown as XML to allow pasting into the form) is:
    SUBSTITUTE('<RequestHeader Type="Invoke"> <InitiatorType />
<InitiatorName /> <SourceName /> <TargetName /> <RequestData>
<Name>SP!</Name> <Method>FireGenericNotifySp</Method>
<Parameters> <Parameter>{0}</Parameter> <Parameter>{1}</
Parameter> <Parameter>{2}</Parameter> <Parameter>{3}</
Parameter> <Parameter ByRef="Y" /> </Parameters> </RequestData>
</RequestHeader>', E(ToParm), E(SubjectParm), E(CategoryParm),
E(BodyParm))
  • If you have multiple intranets that do not serve all sites and you want the application event to fire across intranets, you must set up an event global constant for each intranet (or site) URL and select one of those at runtime.
  • The sample action shown here assumes that the originating user has the same password on the source and target sites, which allows the user to log in for the Invoke. If this may not be the case, you can instead set up a generic remote user, with permissions only to perform this one Invoke, and specify the USERNAME() and PASSWORD() parameters on the Dispatch IDO Request action. Alternatively, you can adjust the USELOCALPASSWORD() parameter.
  • To perform a different type of remote work, you can set up your own application events with handlers and actions to address the work that you require. Then you can create stored procedures to fire those application events. Finally, call those stored procedures using Dispatch IDO Request actions in the appropriate existing handlers.
Related topics