IBM Worklight – Part 3: Best Practices

So far, we have looked into folder structure, logging device information, splash screen, Offline Mode, State Manager and Navigation. In this final part, we will look into callbacks, source control and finally put together all our learnings and come up with an InitPage.js that implements all Best practices discussed so far.

1) Callbacks:
Callbacks form an essential part of JavaScript and it is always a good practice to keep callbacks clean and simple. There is not much material on the Web about DOJO callbacks other than dojo.deferred. Here is a simple callback function in DOJO that can be used as an example:

The following function will initiate a callback i.e. call getCurrentLocation – wait for it to execute and then call drawMap with obtained value rather than proceeding asynchronously.

2) Source Control:
worklightServerRootURL in application-descriptor.xml needs to have a process in place to customize Worklight URL for each environment ${local.IPAddress} is pretty generic and may not work when environment is clustered.

iPhone and Android folders have nativeResources folder which is a great place to have all icons for the app. When checking in the project into Source Control, it is a best practice to check-in common folder (source code) and just nativeResources folder in iPhone, android and other devices if any (windows, blackberry). It is always a good practice to have native code generated every time on developer workstations and through build scripts from common code. If assets under js folder are modified there is an option to check them in as well but if an App is running the same codebase, the folders in blue are the ones that must be checked into Source Control.

application tag has an id field which should match mainFile name in application-descriptor.xml i.e. if the id says ‘hello’ mainFile should be hello.html Altering the id field means changing the main file name as well. If they are not in sync, the App might have issues running on various platforms as native code is generated based on this assumption.

If dojo is employed, make sure the app.id in build-dojo.properties is the same as id in application tag 

Putting it All Together: After implementing the best practices we talked about in the 3 part series, an InitPage.js looks like the following:

The above snippet would be the skeletal structure of main JavaScript for a Worklight Starter application. However, the actual implementation would have more controllers, variables and utility methods. This structure makes the Application versatile and easy to adapt to changes.

Conclusion:

I hope you have enjoyed this 3-part blog series on Worklight best practices. If you have any questions or would like more information, please email solutions@prolifics.com. For more information about Prolifics, please visit www.prolifics.com.

If you would like to connect with me, please add me on LinkedIn and follow me on Twitter! I would love to hear your thoughts on this series and your experiences with IBM Worklight.

Laks Sundararajan is a Solution Architect with Prolifics and a key member of highly specialized team working on IBM WebSphere Portal, Content Management and Collaboration technologies. He has led the implementation of many global projects using IBM WebSphere Portal and has extensive background in design and development of enterprise portals. He specializes in providing Enterprise SOA solutions leveraging WebSphere Portal, Content Management, Tivoli and Mashup’s. He holds Masters in Information Technology from Carnegie Mellon University and a Graduate Degree in Engineering from BITS, Pilani.

IBM Worklight – Part 2: Best Practices

In the initial part of the series, we focused on the folder structure, logging device information and splash screen. In this part, we dive deeper into core Worklight features and focus on Offline Mode, State Manager and Navigation. Let us get right to the subject.

1. Offline Mode/ Processing:
Even though Mobiles are supposed to have 24*7 connectivity; reality is different. Given that every Application should implement Offline Mode. To enable Offline Mode, modify body tag of InitPage.html as follows:

Now, implement doConnectionFailure() method inside InitPage.js

Additionally, have a global busy indicator that could be used across pages to show processing cycles. This will ensure in uniformity across applications.

Applications can then show/hide busy indicator as follows:

2) State Manager:
Mobile Applications need to manage state on client side. This could be achieved through a State Manager that intercepts each View and stores relevant information globally. A code sample that illustrates the same is shown below:

The following snippet is present in InitPage.html to define the view name.

3) Navigation:
Navigation is key part of Mobile Applications. Implementing a versatile framework is essential for a quality application. Content fragments should be isolated so that they can be sourced from external systems if needed. It is also a best practice to keep UI in small pieces as opposed to a single large HTML serving up the entire application.

A sample snippet that implements recommended navigation framework in InitPage.html containing to 2 pages: demo1View.html and demo2View.html is shown below:

Now, demoView.html contains the following snippet to take the user back to InitPage.html. Note that mainView corresponds to view name in InitPage.html. For more details on views, refer to StateManager.

If the snippets are present in same page moveTo should be employed in both places. The above example is for navigating between fragments.

Laks Sundararajan is a Solution Architect with Prolifics and a key member of highly specialized team working on IBM WebSphere Portal, Content Management and Collaboration technologies. He has led the implementation of many global projects using IBM WebSphere Portal and has extensive background in design and development of enterprise portals. He specializes in providing Enterprise SOA solutions leveraging WebSphere Portal, Content Management, Tivoli and Mashup’s. He holds Masters in Information Technology from Carnegie Mellon University and a Graduate Degree in Engineering from BITS, Pilani.

IBM Worklight Series – Part 1: Best Practices

IBM Worklight provides an open, comprehensive and advanced mobile application platform for smartphones and tablets, helping organizations of all sizes to efficiently develop, connect, run and manage HTML5, hybrid and native applications.

Worklight Supports the following frameworks for developing HTML5 and Mobile Applications

• DOJO
• Sencha Touch
• JQuery

Out of the above frameworks DOJO is widely used by IBM in their Portal and BPM suite of products and signifies IBM’s choice when it comes to RIA Frameworks.

In this 3 part series, we talk about Best Practices for developing Worklight based HTML5 and Mobile Applications in general. Note that some of them specific to DOJO Framework. However, parallels can be drawn and similar practices could be employed for Sencha and JQuery frameworks as well.

In the initial part, we focus on the folder structure, logging device information and splash screen.

1) Folder Structure:
Following is the recommended folder structure for Worklight Application (common folder)

Creating controllers and widgets folder under js folder helps in better organization of JavaScript assets as opposed to a single folder. Having a folder for html assets provides a clean structure and avoids them residing directly at root level.

When a Worklight built HTML5 Website or Mobile Application loads, InitPage.html or rather defined under application-descriptor.xml is invoked. A JavaScript file with same name InitPage.js contains necessary scripting information for the framework. Interactions between various components are shown below for better understanding. We will be discussing more on Web Framework in next couple of installments.

For the purposes of this discussion we call the as InitPage.html and main JavaScript file as InitPage.js. Normally, these are named as per Application created i.e. An Application with name ‘HelloWorldApp’ would have HelloWorldApp.html and HelloWorldApp.js as main HTML and JavaScript files.

2) Logging Device Information:
It is always a good practice to log device specific information for troubleshooting/ audits given the vast number of platforms and devices available today. This could be accomplished by calling the simple function below from a dojo listener in InitPage.js

3) Splash Screen/Text:
Mobile Applications have an initial splash screen that is displayed when an Application is launched. Following that, the initial page (in this case InitPage.html) is loaded. While the page is loaded, it might take a few seconds for framework libraries and CSS to load and user may experience a noticeable blip. To prevent this from happening, it is always a best practice to show some text/image when InitPage.html gets called for first loaded (call it as secondary splash screen/text). This is accomplished as follows:

Add the following snippet to InitPage.html

Add the following snippet to InitPage.js and call the function from dojo listener after page is loaded

In the second part of the series, we will be looking at some core features like Offline Mode, State Manager and Navigation.

Laks Sundararajan is a Solution Architect with Prolifics and a key member of highly specialized team working on IBM WebSphere Portal, Content Management and Collaboration technologies. He has led the implementation of many global projects using IBM WebSphere Portal and has extensive background in design and development of enterprise portals. He specializes in providing Enterprise SOA solutions leveraging WebSphere Portal, Content Management, Tivoli and Mashup’s. He holds Masters in Information Technology from Carnegie Mellon University and a Graduate Degree in Engineering from BITS, Pilani.

Error Handling for Composite IBM DataPower Services

In general, when it comes to error handling i am a big believer in “Defense in Depth”. I prefer a multi-layered approach in which I try to account for the maximum possible conditions at each layer and eventually have a “catch all” net where I catch and process the errors that ‘slipped through the cracks’.

Let’s take a scenario where we have an orchestration service which is tied to a bunch of back-end proxy services. Each of the back-end proxies is tied to corresponding back-end application.

Below is the logical representation of a complex composite service on IBM DataPower:

Below is a description of the “Happy Path” i.e. the ideal scenario in which there is no error:

1. The incoming request is received by the ‘Orchestration Service’.
2. The orchestration service then makes a series of calls to the various back-end proxies. The request message for each call is dependent on the response messages from the previous calls.
3. The back-end proxy receives the message and in turn calls the back-end application.
4. The back-end application processes the message and replies with a response message.
5. The back-end DataPower proxy receives the response, reformats it and forwards it to the orchestration service.
6. The orchestration service receives the response and reformats it. It then either calls another back-end proxy, or forwards the reformatted message to the calling service.

Below is the description of handling error scenarios or the “unhappy path”.

Following are the various types of errors that we have to contend with:

1. Errors occurring in the back-end applications: These errors occur when the back-end application is able to successfully receive the request message from the DataPower proxy, but is unable to process it. This condition results in DataPower receiving a fault/error message from the back-end application
2. Errors occurring in the DataPower back-end proxy: These errors occur when the back-end DataPower proxy receives the request message successfully but is unable to process it. This results in the back-end DataPower proxy returning a fault/error message to the orchestration service.
3. Errors occurring in the DataPower orchestration service: These errors occur when the DataPower orchestration service receives the request message successfully but is unable to process it. This results in the DataPower orchestration service returning a fault/error message to the front-end calling service.

With that in mind, following is my preferred approach for complex composite DataPower services:

Errors occurring in the back-end applications:
The orchestration service checks if the response from the back-end proxy is a soap:fault, and it if is then it might decide to rollback any of the previous calls (like an adduser or a insert DB row) with another call(like deleteuser or delete DB row).

You can use the dp:url extension to do this:

These errors come back as soap:Fault messages with HTTP Response code ‘500 Fail’. Generate a custom error message which includes the following fields (at least):

• Error Code service variable
• Error Details service variable
• Timestamp service variable
• MsgId/UUID response payload

Now, convert the HTTP Response Code from ‘500 Fail’ to ‘200 OK’:

We convert the HTTP Response Code from 500 to200 so that the orchestration service treats the soap:fault message as a valid response instead of an error.

Errors occurring in the back-end DataPower Proxies: Such errors can be caught and processed by using a combination of the On-Error action with the Error Rule in the back-end proxy’s policy.

The error rule can be configured to generate a custom fault/error message with HTTP response Code set to “200 OK”.

Errors occurring in the Orchestration service: Again, such errors can be caught and processed by using a combination of the On-Error action with the Error Rule in the orchestration service’s policy. We send back the error message with a HTTP Response code of “500 Fail” to the front-end calling service.

Prithvi Srinivasan is a Technology Manager at Prolifics and has extensive expertise in the IBM WebSphere suite of products. He has played a key role at several strategic clients by providing technical leadership. Prithvi has an extensive background in the design and development of SOA and Integration solutions, with a proven track record of consulting and architecting solutions for several industry verticals like Banking, Finance, Retail, Insurance, HealthCare and Technology.

ILOG Integration with Process Designer (IBM BPM 7.5.1)

Some information I gathered on best practice of ILOG Integration with Process Designer (IBM BPM 7.5.1):



Connecting JRules directly from IBM BPM Via Webservice-SOAP connector:

Just want to add that this is not a best practice, but a nice description of one way to integrate BPM 7.5.1 with JRules. There are multiple factors that impact the integration pattern. You always have to consider the information model in scope for the rules, that is far different from the model for the process. So the BPD will most likely not be able to send all the data to JRules. There is always a middle man, service, responsible to populate the data graph needed for the rule processing. With BPM Advance this could be a SCA component integrated as Advance Integration Service, in BPM Standard a java component exposed as web service and consumed as such within the BPD.



JRules connector directly in IBM BPM

The goal of embedding the ILOG rule editor inside IBM BPM is to provide a much simpler way to modify the behavior of the processes. Those rules live within the process and as such a new version of the process needs to be redeployed every time a rule needs to be changed.



SOA Best Approach:

The SOA based approach for Business Process Management suggests the options as below:


1. Blueworks Live -> Business Process Manager

2. ILOG(create Business rules) -> Websphere Integration Developer -> Process Server



Identify the Hosted Transparent Decision Service (HTDS) interface
.
Create an SCA library for HTDS WSDL. 

Defines a mediation module for the interface mapping. 


Joel Krishnan, a Solution Architect for Prolifics, has over 9+ years of IT experience and has worked in many customers implementing technology solutions across multiple business verticals.He is specialized in IBM BPM specifically in ProcessDesigner.He has extensive experince in Architecture/Design and Devopment of IBM BPM.He is also certified in IBM BPM. Joel received his BE in Electrical Engineering in 2002.

How to Delete Process Applications from IBM BPM 7.5.1

As a new feature of the Business Process Manager V7.5.1 platform, process applications can now be deleted from the repository. In the previous version of BPM, version 7.5.0 & 7.5.0.1, users could only archive snapshots within a process application. This did not remove the application; rather it was merely hidden from the default view and it was still stored in the repository and the database.

In the latest version of BPM, users can now actually delete the process application, and in turn, delete all snapshots and instances tied to that application, including deletion of these entries from the database.

To delete a process application, click on the process application that you want to delete and then click on Manage.

Next, click on Archive Process App and click on Archive.

Click on the Process Apps tab of Process Center and then click on Archived.

Click on the process app that you previously archived and select Delete Process App, click on Delete.

If you then return to the Process Apps tab in Process center, you will notice that the process app no longer appears in the list.

We can actually confirm that all database entries are also removed as part of the process app deletion. Here we can see that the entry for our application named TestApplication was added to the BPMDB in the table LSW_PROJECT.

After deleting the process app, this entry is no longer present in the table. If the application contained snapshots and BPDs, these entries would also be removed from the LSW_SNAPSHOT and LSW_BPD tables respectively.

Please keep in mind, that this cleanup only happens in Process Center. Currently, the product does not have the capaibility to clean up these components on the Process Server side. However, this is an important new feature to help keep your Process Center repository clean and its database clean and efficient.

Seth Gagnon, a Senior Consultant for Prolifics, has over eight years experience in the healthcare industry and has worked with business process management technology to automate member enrollment and claim adjudication for a Fortune 200 healthcare client. He has experience in IBM middleware products such as WebSphere Application Server, WebSphere Process Server, WebSphere Business Process Manager, and other products in the IBM BPM stack. Seth received his BS in Management Information Systems from the University of CT and his MS in Technology Commercialization from Northeastern University.

Leveraging IBM Rational to Manage your WebSphere Environment

We’re gearing up for another exciting Innovate 2012 conference in Orlando this year, having just come back from presenting at the IBM Impact conference in Las Vegas. The great thing about these conferences is they give Prolifics the opportunity to share stories and lessons learned with customers old and new – and lets us bring a number of our customers together so they can swap ideas amongst themselves.

Over the last year, since Innovate 2011 conference, Prolifics has helped a number of our WebSphere customers improve their configuration and release management processes through a combination of good practices and IBM Rational tooling. We’ve seen weaknesses in these areas be a major drag on otherwise technically sound development projects – and helping both our own as well as our customers’ teams improve in these areas has been a top priority of my own practice within Prolifics.

In addition to sharing our experiences at IBM Innovate, I am introducing them in this Prolifics whitepaper as well: Leveraging IBM Rational to Manage your WebSphere Environment.

To learn more about my upcoming speaking session at IBM Innovate and Prolifics’ presence at the conference, click here.

 @greg_hodgkinson

Gregory Hodgkinson is the Rational Practice Director at Prolifics (www.prolifics.com). Previous to that he was a Founder, Director, and the SOA Lead at 7irene, a visionary software solutions company in the United Kingdom. He has 16 years of experience in software architecture , initially specializing in the field of component-based development (CBD), then moving seamlessly into service-oriented architecture (SOA). His extended area of expertise is the Software Development Lifecycle (SDLC), and he assists Prolifics and IBM customers in adopting agile development processes and SOA methods. He is still very much a practitioner, and has been responsible for service architectures for a number of FTSE 100 companies. He presents on agile SOA process and methods at both IBM (Rational and WebSphere) and other events, has also co-authored a Redbook on SOA solutions, and contributes to DeveloperWorks.