Posts tagged HowTo

BlazeDS – message selectors vs subtopics

Let’s assume that in a Flex/BlazeDS application you have a destination and a number of producers and  consumers associated to that. All the messages created by the producers are received by the consumers, and sometimes you don’t want that – you need to send the message only to a specific consumer or to a specific subset. For example you may have a chat application, so you should be able to offer features like private messaging or the ability to send messages only to some selected users.

In order to implement that you can use message subtopics and message selectors. Both options are described in details in BlazeDS manual, however an important detail related to them is missing – what are the advantages and disadvantages in both cases. Below I’ll try to write the most significant one, related to performance.

The advantage of using selector is the fact that you can define complex expression in order to filter the clients – for example you can use SQL92 conditional expression syntax when testing the message header. The producer can add a string in the message header and every message will be scanned using Consumer selector. The disadvantage is related to performance – every message will be scanned using the consumer selector, and if you have a large number of consumers it can significantly hinder performance, so one should be be careful when using it.

The advantage of using a subtopic is related to performance. BlazeDS will build behind a HashMap per subtopic containing all the associated customers. When a message is produced it will be send to the customers from the corresponding map, without testing for a condition. If the number of consumers with the same subtopic is small compared with the total of consumers the performance difference between selectors and subtopics can be very large.

In conclusion try to stick with subtopics – in most of the cases you don’t need the selector flexibility.

—-
Original article at http://cornelcreanga.com/2010/09/blazeds-message-selectors-vs-subtopics/.

The LCES Pet Store & Process Oriented Application Development!

Shone Sadler

This is one of three demos that I did at MAX 2008. Unfortunately, I did not make it through all the demos due to technical issues (i.e. I should have come earlier to test out the gear). Enough of the excuses though, hopefully people enjoyed what I could show and now here is the source ;-)

The primary purpose of this demo was to show a) a “traditional” enterprise app being built solely on top of LCES and b) the diverge from typical Data Oriented Applications that interact directly with the underlying DB to Process Oriented Applications that leverage Long-Lived processing to build a more rich end-to-end experience.

Click HERE to download the source code.

Note the download is a zip file (LCESPetStore.zip) containing 3 files:

  1. PetStore.zip (My Flex Project) – This App is currently hardwired to talk to localhost.
  2. petstore-dsc.jar – The LiveCycle Data Management Services Assembler that Creates, Reads, Updates, and Deletes Pets from the DB along with the Java source. This DSC also creates the underlying DB table when it is installed, however the DDL is generated for MySQL only currently.
  3. PetStore.lca – The LiveCycle Application Archive that contains the Pet Verification Process and XFA Form used in the Application

The Architecture
Below is a slide of the overall architecture.

LCES PetStore ArchitectureLCES PetStore Architecture

Note that only the highlighted boxes are complete in the demo (sorry I didn’t get to the rest;-( .
A brief description of the highlighted Boxes are:

  1. The LCES PetStore AIR application
  2. The Pet Verification Process – A long lived process that generates a form/workitem that is routed to the store clerk (Tony Blue)
  3. The Pet Detail Form – the one that is rendered to Tony Blue
  4. The User Service – An out of the box service used to make User Assignments as part of a process
  5. LiveCycle Workspace – An operational UI provided out of the box for users to manage workitems and participate in long-lived processes.
  6. The PetService – A Custom service that implements the CRUD operations necessary to manage Pets in the Database and to push them to clients via LiveCycle Data Management Services.

For purposes of this demo I decided to use Mate. I was originally motivated by the excellent presentation that I saw from Laura Arguello at the Atlanta Flash & Flex User Group back in September. This is my first time using Mate, so hopefully I paid it some justice here. At MAX 2008 I laid out the following slides to show how MVC related to LCES and Mate to LCES respectively.

MVC & LCESMVC & LCES
Mate & LCESMate & LCES

Anyway, I have two more LCES demos to post over the weekend (the Zillow App and UDDI Browser), so keep an eye out!

—-
Original article at http://lostintentions.com/2008/11/21/the-lces-pet-store-process-oriented-application-development/.

UDDI Integration with LiveCycle

Shone Sadler

On several occasions I have been asked about the possibility of integrating LiveCycle ES with UDDI to provide a standards based way of browsing LiveCycle services. Well I figured MAX2008 was a good motivator for getting such an integration working and so that is what I kicked off several weeks prior to MAX. I decided I would build a LiveCycle Component that allowed for both the publishing and querying of data to and from UDDI from within LiveCycle. Unfortunately, I quickly realized that there still seemed to be limited tooling around UDDI. So while, I could use a complete Java implementation of the UDDI specification from Apache, JUDDI, there was no easy means for me to browse the registry to show the results. This inevitably lead to the 2nd part of this proof of concept which was to build a UDDI browser with Flex. Note: there is an open source Java UDDI Browser available at http://uddibrowser.org/ that works well, however using it for a UDDI LiveCycle demo didn’t seem right for my purposes ;-)

Walkthrough
You can view an entire walkthrough at screencast.com Or the following lower res videos at YouTube.

 

So why did I create this demo?

  1. To provide a Proof of Concept for Integrating LiveCycle with UDDI
  2. To Discuss features and concepts around the LiveCycle Registry
  3. Learn How-to(s) with Flex and Web-Services (i.e. another excuse for me to improve my Flex chops)

IMPORTANT DISCLAIMER: This was a demo done as a proof of concept for which I am making the source code available. However note that the LC Component, and UDDI browser need a lot of fine tuning, which I have not and probably won’t have the time to complete anytime soon. The demo did accomplish its goal of proving that it is not only possibly but very feasible to integrate LCES with UDDI.

Architecture
Below is a high-level diagram for the architecture of the UDDI/LCES proof of concept.

LCES UDDI ArchitectureLCES UDDI Architecture
  1. JUDDI: A Java based implementation of the UDDI 2 Specification which was used for purposes of this demo. You can find more info about JUDDI at http://ws.apache.org/juddi/
  2. UDDI Component: A custom LiveCycle component deployed in a LiveCycle Instance capable of querying the LiveCycle Registry and publishing service meta-data to a UDDI Registry
  3. UDDI Browser: An AIR application for browsing Businesses, Services, and TModels in a UDDI Registry.

LiveCycle ES Registry
The “Collective” Registry within LiveCycle ES is made up of at least 6 sub registries that store meta-data around the components deployed within ES. The meta-data in the LiveCycle Registry is used at both Runtime (e.g. Service & version resolution) and Designtime (e.g. to build composite applications).

LCES RegistryLCES Registry
  1. Component Registry: Stores the base information relevant to a component such as component id, title, description, etc…
  2. DataType Registry: DataTypes are Java classes that are exported from a component and that can be leveraged by the LCES tooling
  3. PropertyEditor Registry: Property Editors are UI elements implemented in Java that control the visual rendering of types and properties within LiveCycle ES tooling.
  4. Connector Registry: Connectors are integration mechanisms that define a means by which to invoke a LiveCycle service. Example connectors include EJB Connector, SOAP Connector, and VM Connector.
  5. Service Registry: Maintains all the meta-data we have around services such as the signature of a service, description, hints, config values, etc…
  6. Endpoint Registry: Stores configuration necessary to bind a service to one or more connectors. This provides for the loose coupling between service implementations and the means by which they are invoked (i.e. Connectors).

Trying out the UDDI Proof Of Concept
Unfortunately, I have not setup an environment where demos such as this are available online.
For now however you will need to do the following steps:

  1. Download and install the LiveCycle trial (if you haven’t already) from http://www.adobe.com/devnet/livecycle/trial/.
    Note: This demo was built on LCES Update 1 (also known as 8.2.1)
  2. Download the Source Code for a) the AIR app and b) the LiveCycle Java Component (i.e. uddi-dsc.jar) used from Download Source Code Note: uddi-dsc.jar contains the related Java code within
  3. With LiveCycle up and running go to LiveCycle Workbench and click on Window–>Show View–>Components. In the Components view you can right click the top node to then install the Java Components downloaded (i.e. uddi-dsc.jar) Note: You will need to configure the UDDI3Service by right clicking it in the components view, setting the user/password expected by JUDDI (‘admin’/” for me), and setting the publishAsHost & publishAsPort (used to fill int the WSDL URL in the UDDI Registry)
  4. Import the Flex Project included in the Download to your Flex Builder environment
  5. Run the AIR APP!
  6. Oh wait….. Before any LC Services are available in the UDDI Registry you need to invoke the UDDI2Service.publishLiveCycleService. You can do this from the “Components View” in Workbench, however, you need to first turn on the unsupported workbench option –> -Dcom.adobe.workbench.unsupported.dscadmin.invoke.enable=true in the workbench.ini file

Anyway, Good Luck! there is a lot to play with there.

Few more notes for those digging deeper:

  • I packaged two modified WSDLs from which the WebService ActionScript stubs were generated within Flex Builder. I had to modify the WSDL to get around issues with the decoding of arrays.
  • If you need to regenerate the WebService ActionScript stubs then you will need to modify the src/webservices/inquiry/BaseInquireService.as file to change the isWrapped properties of the WSDLMessages to false rather than true.
  • The calls between LiveCycle and JUDDI seem to be slow on the perf side, but I haven’t drilled into that aspect as of yet

—-
Original article at http://lostintentions.com/2008/12/08/uddi-integration-with-livecycle/.

Extending PDF support within Microsoft SharePoint

I’m seeing a lot of organisations adopt Microsoft’s SharePoint server lately and one common discussion point is around PDF workflows and how to support functions such as Check In / Check out etc. For those users out there, you’ll be please to know that Adobe has quite a few new ways for you to extend your SharePoint workflows into […]

—-
Original article at http://feedproxy.google.com/~r/MarkSzulcsBlog/~3/68eLN7kHFy8/.

Using JRockit Mission Control to Determine CPU Utilization by LiveCycle JVM Thread

Jayan Kandathil

If you are using Oracle WebLogic using the Oracle JRockit JDK (“Mission Control” or “Real Time“, the only difference is licensing, not technology), you can use “JRockit Mission Control” (JRMC) to determine which LiveCycle JVM thread is using up CPU cycles.

Download JRockit Mission Control from OTN (Oracle Technology Network) and install it locally on the same server as WebLogic. Make sure you are properly licensed to use these tools.

1) Run jrmc.exe from the bin folder.
2) In the left navigation pane, dbl-click the WebLogic instance (automatically discovered) under the ‘Local’ node
3) Click the ‘Runtime’ button
4) Click on the ‘Threads’ tab (at the bottom)
5) Check the ‘CPU Profiling’ checkbox
6) Sort on the ‘Total CPU Usage’ column

Checking the ‘Allocation’ checkbox will cause JRMC to report memory usage by JVM thread.

——-
Original article at http://blogs.adobe.com/livecycle/2011/03/using-jrockit-mission-control-to-determine-cpu-utilization-by-livecycle-jvm-thread.html.

Tutorial: Designing Interactive PDF Forms

- Drew Brazil

With LiveCycle Designer you can create interactive PDF forms. Interactive PDF forms are useful for gathering information from recipients who want to complete and submit the form online, as well as print a copy of the form.

Below is a link to a comprehensive tutorial written by Samartha Vashishtha, which explains how to create and distribute an interactive form. This tutorial discusses how to create the form, key consideration to keep in mind while creating the form, how to distribute the form, how to manage responses, and how to use scripting for conditional fields.

The tutorial also includes a link to a sample form, which you can view as you follow along.

For more information, see http://ewh.ieee.org/soc/pcs/index.php?q=node/1879

——-
Original article at http://blogs.adobe.com/livecycledocs/2011/01/tutorial-designing-interactive-pdf-forms.html.

Using LiveCycle Data Services to create applications

- Scott Macdonald

Did you know that you can use LiveCycle Data Services to create interactive applications that display run-time data? If you are interested in knowing how to program these types of applications, then i recommend checking out this article: Creating live stock quote sample applications using the Message service.

——-
Original article at http://blogs.adobe.com/livecycledocs/2010/12/using-livecycle-data-services-to-create-applications.html.

Java exceptions and Flex

I’ve seen some articles on this subject but I have not found one dealing with all cases (webservices, BlazeDS, BlazeDS and Spring, data management). Also the approach for BlazeDS is different than the one used with Spring/BlazeDS integration, and this thing can be a little bit confusing for a beginner.

Let’s assume that you have a layer of services that should be invoked from your Flex application. You can expose these services as web services or as remote methods. Or you can use data management. The Java methods may throw errors and you want to display them in the Flex application.

For simplicity I will use a very short method as an example. The method signature is :

public String returnResults() throws DatabaseDownException;

There are four main use cases:

a)You have to write a webservice to return the result as XML. For example:

<?xml version="1.0" encoding="UTF-8"?>
<data>
<result>
</result>
</data>

In this case you will need to enhance your XML to add a structure for keeping error messages – like this:

<?xml version="1.0" encoding="UTF-8"?>
<data>
<result>
</result>
<error>
</error>
</data>

When building the XML the <error> body is going to envelope the exception message. Of course more information can be added, including exception type, severity, and so on. The same approach should be used also when working with SOAP services

b)You plan to use BlazeDS and Java remoting

In this case things are going to be easier,  because BlazeDS is able to automatically serialize the thrown exception and you can find the serialized exception in the FaultEvent object. Assume that you have the Java exception declared below. It extends the RuntimeException and it has a getter method for a custom field.

public class DatabaseDownException extends RuntimeException{
private String customField;
public String getCustomField(){
return customField;
}
}

The Flex code declares a remote object and registers a handler (which is also included) for failure.

<mx:RemoteObject id="test" destination="testDestination" result="resultHandler(event)" fault="faultHandler(event)"/>
private function faultHandler(event:FaultEvent):void{
var exception:Object = event.fault.rootCause;
Alert.show(exception.cause);
Alert.show(exception.localizedMessage);
Alert.show(exception.message);
Alert.show(exception.customField);
}

There are four fields in the serialized exception. The first three are inherited from the Throwable object, the last one is declared in your exception. It is interesting to note that you need not have a pair of set/get function in order to have your property serialized. The Throwable object is the only object in which  it is enough to have get methods in order to serialize the values (you can take a look at flex.messaging.io.ThrowableProxy to check that).

The only drawback is that you are working with untyped objects..if you don’t like that you can throw instead instances of flex.messaging.MessageException. This Java class is part of the BlazeDS and it will be deserialized using the class mx.messaging.messages.ErrorMessage (obtained from the event.message property).

You can add your custom data in the MessageException class using the extended property. For example:

MessageException messageException = new MessageException();
HashMap<String,String> map = new HashMap<String,String>();
map.put("clientName", "JOHN");
map.put("clientSurname", "MASTER");
messageException.setExtendedData(map);
messageException.setCode("ACCOUNT_DISABLED");
throw messageException;

And on the Flex side:

private function faultHandler(event:FaultEvent):void{
var errorMessage:ErrorMessage = event.message as ErrorMessage;
trace(errorMessage.extendedData.clientName);
trace(errorMessage.extendedData.clientSurname);
trace(errorMessage.faultCode);
}

You probably do not want to have an explicit dependence between your service layer and the BlazeDS libraries, so in this case you should build a delegate on top of it, which will also act as an exception translator.

c)Using Spring BlazeDS Integration

You have several benefits when using Spring BlazeDS integration, and if your middle tier is already using Spring it’s a must. The benefit related to exception handling is the exception translator mechanism. This translator will catch all the exceptions thrown from the services invoked from Flex and you can translate them into something more meaningful for the client.

First you need to declare the exception translator:

<bean id="exceptionTranslator" class="com.test.exception.ExceptionTranslatorImpl" />
<flex:message-broker services-config-path="/WEB-INF/flex/services-config.xml">
........
<flex:exception-translator ref="exceptionTranslator" />
</flex:message-broker>

The exception translator is below:

public class ExceptionTranslatorImpl implements ExceptionTranslator{
//handles all
public boolean handles(final Class<?> clazz){
return true;
}
public MessageException translate(final Throwable throwable){
if (throwable instanceof DatabaseDownException){
MessageException exception = new MessageException();
exception.setCode("FATAL_DB_DOWN");
return exception;
}
if ...........//check another things
}
}

Note that in the current version of Spring/BlazeDS integration it is mandatory to have an exception translator, otherwise the original error is going to be swallowed and you will receive some generic error.

d)Using data management

The same approach from point c) applies here. Basically your assembler – which is going to invoke some service to obtain/create data – will take care of translating the exceptions into something meaningful for the client. I wrote some time ago a short post about that here.

Note: this article was translated also in Belorussian (thanks Patricia), you can find it here.

—-
Original article at http://cornelcreanga.com/2010/05/java-exceptions-and-flex/.

Go to Top