Incoming 1 - Action Mapping. The runtime platform processing starts when the XGate servlet receives a request from a client. Upon receipt XGate will attempt to map the requested action to a server Controller using the mapping.xml file. This file is located at webapps/doc and should be maintenance free. Incoming 2 - XGate Custom Plugin. Once an action has been mapped XGate will search for any Custom Plugins that may be defined. These are custom Java classes and described in the xgate.xml file located at webapps/doc. If custom plugins are found then the incoming request message will be sent to the plugins. Once plugins have finished processing the resulting message will be forwarded to the View node for onward processing. An example plugin may call an LDAP server to obtain security credentials and provide this information as an XML fragment for example. This information can then be used within the Controllers to restrict access to remotes services, validate against remote services, control access to page menus, etc. Incoming 3 - Data Binding. The next step binds the incoming name-value pairs to the XML instance document if one was provided and binding was requested. Incoming 4 - View Node. This is the first native rules-based processing node of XPlatform and should be largely maintenance-free, although it has rules capabilities just like any other Controller and its behaviour can be modified if necessary. During the incoming request leg, the View node inspects the incoming message to determine the Controller name. It then uses this to forward the message to that controller for further processing. You may notice by this stage there is a default wrapper that has been applied by WebMaker. This is applied by XGate and should not require modification. This wrapper enables you to separate WebMaker and remote service-specific header information from the data/message payload information. Any information that was not bound will appear in the /mvc:eForm/mvc:Control section of the message. The other Fields indicate the action and the target controller and also the name of the next page. The page name may be changed by the Controller on the response leg, depending on the execution outcome. Incoming 5 - Controller Logic. Once the request message reaches the controller you can process the message using any number of native XML operations such as copying, deleting, validating, transforming, etc., You can also use the Invoke Service operation to call remote services and other Controllers. These other controllers may be custom coded. See later. For a full list of available operations please see the RuleMaker User Guide. Incoming 6 - REST, Remote Service Security and HTTP Programming. WebMaker separates the business application from the technical plumbing required to connect together a SOA application. This includes the transport requirements for communicating with remote services. There may be occasions when you need more detailed control of the underlying HTTP communication. This can be achieved using the XGate HttpHeader fragment. Please see later section on REST for more details. Incoming 7 - Access Services (including Proxy node) When a WSDL is parsed WebMaker automatically sets up an Access Service for each of the services defined in the WSDL. The access service also wraps request messages, calls the remote service, processes the response and unwraps the response ready for processing on the outgoing response leg. The proxy service shown simply acts as a placeholder for the remote service address. This occurs when a node is designated as a Remote Service Proxy in the deployment screen (Please see XDE User Guide for more details). Nodes defined as Remote Service proxies have no internal structure or rules capabilities. They simply become a configuration parameter at runtime. All pre and post processing for remote service calls should be performed in the Controller and, if the change applies to all operations of the remote service such as the caching and submission of security tokens, then the Access Service rules can be modified. Outgoing 1 - Error Checking, Unwrapping, caching, etc. When a service call returns it will typically be wrapped and may include information that needs to be sent back with subsequent requests, such as record ids and security tokens, etc. The Access Service node can be used to handle such tasks. By default, rules for Fault checking and message unwrapping are generated by WebMaker when WSDLs are imported. Outgoing 2 - Controller Logic This presents the opportunity for processing before the information is transformed for output to the next screen or other calls are made to other services. This is also the stage when you can set the page name for the next screen. This is the page name that will be used by the View node to locate the transformation to generate the next page. At this stage you should also ensure that the XML instance that was used for the Page Display Bindings is located in the right place to enable page transformation to perform the correct bindings. If the information is missing or in the wrong format then the screen with contain blank or incorrect data and structures. Outgoing 3 - View Node In almost all cases this stage simply transforms the data returned by the Controller using the next page name to create the next page. You can add generic rules here to redirect to an error page or perform logs, etc. if there are errors present. If a translation parameter was provided during the request then the translations will be applied at this stage. Outgoing 4 - XGate Custom Plugin At this stage you should write the output part of Custom Plugins if you decided to use one. The response will be forwarded to the plugin before being sent to the browser.