Good Morning EveryOne,

I have the following RESTful scenarios not sure whether it is supported in XAware.

Scenario1:

I have URL http://localhost:8080/test/policy, which up on invoking with HTTP GET method retrieves all the policies, up on HTTP POST creates the policy, up on HTTP DELETE deletes the policy.

Scenario2:

when I call http://localhost:8080/test/policy/1 with HTTP Get, retrives the policy whose id is 1.
when I call http://localhost:8080/test/policy/1 with HTTP DELETE, the policy whose id is 1 id delete.

I searched through forums, help and could not find information.

Can anyone please help me on how can I achieve the above scenarios using XAware.

Thanks in Advance.

Regards,
Venkat Rao.

Venkat,

The HTTP operation (GET/POST/DELETE/PUT) is made available as a connector property (called httpOperation) in your BizDoc. You typically need to create a single top-level BizDoc that reads the property, and performs the appropriate logic to call another BizDoc for each of the individual operations.

For testing purposes, you can print out all the connector properties, plus any other session variable, from you BizDoc with this command:

Code:

<sessionVariables xa:show_session_variables="" />

xa:show_session_variables will take a regular expression an print only what you want. To print only the httpOperation, use this form:

Code:

<sessionVariables xa:show_session_variables="httpOperation" />

The logic in your top level BizDoc needs to read the httpOperation variable, which is accessed as a session variable. A 'switch' statement would look like this:

Code:

<xa:switch xa:value="$xavar:httpOperation$"> <xa:case xa:value="GET"> <callBizDocGET /> </xa:case> <xa:case xa:value="PUT"> <callBizDocPUT /> </xa:case> <xa:case xa:value="DELETE"> <callBizDocDELETE /> </xa:case> <xa:case xa:value="POST"> <callBizDocPOST /> </xa:case> <xa:default> <invalidOperation /> </xa:default> </xa:switch>

For scenario 1, you likely want to use an alias for your BizDoc (xa:alias on the root of the BizDoc). You might have policy.xbd in folder 'test', which is invoked using the fully qualified name "test/policy.xbd". You can create an alias for this called 'test/policy', so the ".xbd" doesn't have to show up on the URI. It is this BizDoc that should check the httpOperation and call the appropriate BizDoc for the proper operation. If you want to get rid of the '/xaware/bizview' from the URI, you can configure the container and servlet (called XAServlet.class). Tomcat lets you specify a root context by changing the name of xaware.war to ROOT.war. To remove the /bizview portion, you would have to modify web.XML to add a servlet mapping (pattern '/*' to be processed by XAServlet). For scenario 2, we have a URI segment mapping feature which will translate something like '/test/policy/1' to '/test?policy=1'. This is the urlParamMap that is accessible through the JMX console, or by setting a connector property in the Spring config for HTTPConnectorProperties (conf/servlet/spring/Connectors.xml). I would actually recommend sticking with query string parameters, unless you have a firm requirement to not use query string syntax. -Kirstan

Good Morning Kirstan,

Thank you very much for your help. It solved the problem to the great extent.

Here I have one issue.

For the scenario 2, In order to access the policy with id 100, I need to use the URL like this.
http://localhost:8090/xaware/bizview/id/100/policies/policy.xbd

Can we have the id details at the end of the URL like, http://localhost:8090/xaware/bizview/policies/policy.xbd/100

Thank you very much for your support.

Regards,
Venkat Rao.

Hi Venkat,

You can set the UrlParamMap to achieve a similar URI, though not exact. You'll need a URI path component corresponding to the parameter name. Within the URI path, two path components are extracted to derive a query string parameter, which then maps to a BizDoc parameter. For example, you'll want a URI like this:

http://localhost:8090/xaware/bizview/policies/policy.xbd/Policy/100

which can then be set up to pass the value 100 into a parameter called 'polNum' or similar. For this configuration, the UrlParamMap would be:

/bizview:/Policy:polNum

Each param map is a triplet that starts with a "context", which is one of the configured servlet mapping paths in web.XML, allowing you to configure multiple sets of maps, triggered by this path component. Next is a path component that is searched using a simple string search. This should be unique. I've upper-cased the 'P' to make it unique, avoiding the name collision with /policy.xbd. The third component is the input parameter name. The triplets are separated by a semicolon (';').

-Kirstan

Hi Kirstan,

Thanks for your help once again.

Actually we are doing a sample application on Policy Creation. In this application there will be some validation rules which are to be passed before creating the policy.

As per my understanding XAware can be used for Data Integration purpose. Do you think is it appropriate to have processing logic in XAware (i.e. validation rules as if else conditions in the BizDocuments) or have some processing logic layer before calling XAware for data persistence?

Once again thanks for your great support.

Thanks,
Venkat.

There are no hard and fast rules for how to partition processing logic and business rules. But it is often appropriate to have processing rules built into your XAware BizView files. Generally, these rules should be closely related to the data integration, like logic determining what data sources to access, what transformations must take place, and guiding the flow of data. Many users also apply higher level business rules right in the BizView file. They have to be coded somewhere, and often it makes sense to place them in the BizView file which are easier to change than in native code. With this approach, you should attempt to parameterize the rules as best as possible (things like thresholds, min/max values, etc) using lookup tables (and Lookup Functoid), that can be easily configured.

If business rules are fairly dynamic, it makes sense to abstract rules into their own layer, so the rules can be efficiently managed using a rules engine. I don't have much experience with this approach - most of the implementations I've been involved with have used the lookup table method to parameterize the rules, with an applet to manage the key parameters in the lookup tables.

Hope this helps.

-Kirstan