Mobile for business users

As I mentioned in a previous blog, Oracle Fusion Apps breaks with Oracle's past in the sense that the user interaction is built from a user perspective. Rather than exposing a datamodel or a business process to the user, they have designed the user interface based on information they have gathered about their user. Their website tells this compelling story, go check it out (after finishing this blog ;).

The world goes mobile

These days you can't just design for the desktop anymore. People use other devices like tablets and mobile phones and these devices are showing up in the workplace more and more. On top of that, people are working from different locations: from the office, from home, en route, or wherever they happen to be. This creates a new challenge when creating services or application. Take for example a HR self service application or an expense report application. Employees expect this functionality to be available everywhere, and on all devices.
At the other hand, organizations are struggling with the application of 'apps'. When I started programming, every piece of software had to have an API. Then the world realized that you want to integrate systems in heterogeneous landscapes and every piece of software needed to have a 'service interface'. Now that we have apps, every piece of software I realize needs to have a REST API so that people can create an app for that. The problem with this approach is that creating a service interface on every piece of software does not create a good service oriented architecture and creating a mobile interface for every piece of software does not create a good mobile user experience for your customers, employees and partners. So how should you approach this?

Oracle Fusion Applications User Experience Patterns and Guidelines 

The ADF User Experience patterns and guidelines site is a very good starting point for organizations that want to start using mobile for their applications. The site has four sections:

1. Design guidelines. This section explains that mobile design differs from designing for desktops. It  then states 10 mobile design guidelines. The most important ones are at the top: know your user and define the essential mobile task
2. Know your user is a separate section that talks about getting to know your user. You have to revisit your idea of your user and determine who will use your application on a mobile device and in what context this will happen. Creating personas is a very good technique that you can apply. The site has some references to this technique at the bottom. 
3. Create a mobile task flow. This section explains how your mobile tasks fit in the overall business process. Unfortunately this section is rather short and uses flow charting to show the flow in the user interface, and not the overall business process. It is very important that the business process and the (mobile) user interaction that is designed from the perspective of the user are aligned: otherwise you get into trouble with rules and regulations that exist in your organization for the business process that people are accessing using their mobile device.
4. Mobile design patterns. Users may not be used to using mobile applications for work, they use it at home and in their personal lives all the time. So using patterns that people are familiair with is important. You as a developer doesn't have to re-invent the wheel when creating the mobile tasks and your users are happy because the application works the way they expect. This will save money because there will less calls to the helpdesk, less errors and your application will actually be used ;)

OBUG Connect

Ultan Ó Broin and me will present some mobile design patterns that are defined in the process of designing mobile applications for Fusion apps at OBUG connect 2013, this afternoon. We will explain the importance of patterns and show some of the patterns that can be built with either ADF Mobile, or the native platform of a device.

Next: apply!

The next step is that projects start using these techniques to built user interaction for professional users, like we have been doing for consumer software for a long time. It is time that professionals get the user experience they deserve and need to be productive and happy while doing their job!

SOA Made Simple

The book SOA Made Simple is published! SOA Made Simple is written by Vennster's Lonneke Dikmans and Ronald van Luttikhuizen. You can download a sample chapter and order the book from the Packt Publishing website. 

SOA Made Simple is a concise and indispensable handbook for finally understanding exactly what Service Oriented Architecture is. Split into three clear sections, in this book you’ll learn from both theory as well as step-by-step implementation examples to aid in your understanding of this often poorly- articulated industry term.

A short abstract for SOA Made Simple:

SOA is an industry term which is often preached like a religion rather than taught like a technology, and over time, grasping the concept has become unnecessarily difficult. Many companies proclaim that they don’t know where to begin with SOA, while others have begun their SOA effort but haven’t reaped the benefits they were convinced it would bring. “SOA Made Simple” explains what SOA is in simple terminology and by using real-life examples. Service-orientation is already a very natural way of thinking for business stakeholders that want to realize and sell services to potential clients, and this book helps you to realize that concept both in theory and practice. After reading “SOA Made Simple” you will have a clear understanding ofwhat SOA is so you can implement and govern SOA in your own organization. If you are an architect who wants to be completely clear in your understanding of what SOA is, then this book is essential. In fact, anyone (designer, developer, administrator or team lead) who is implementing or about to implement an architecture in an IT environment should not miss out on “SOA Made Simple”. 

From the Trenches 3 | Patching OSB and SOA Suite to PS5

In two previous blogs (part I and part II) I talked about a recent upgrade from Oracle Fusion Middleware 11g PS2 to 11g PS5. This blog finishes with a post-installation step that was required to complete the upgrade and a quick note.

All in all, after a good preparation the team was able to patch a production environment to PS5 in almost an afternoon. The environment runs several Fusion Middleware products (OSB, SOA Suite, OID, WebLogic Servers for JEE apps) and spans multiple WebLogic Domains and multiple WebLogic Managed Servers in single-node clusters.

Migrating running composite instances that use While activities

One of the new features in SOA Suite 11g PS3 is that the Enterprise Manager Fusion Middleware Console shows the loop count in the BPEL Audit Trail when using While activities. This is shown in the following figure.

This feature works for new instances that are created after applying the patchset and for running instances that haven't reached the While activity yet when the patchset is applied. However, when you have running instances that are executing a While activity (also when the instance is in the dehydration store), you see the following entry in the SOA Suite log after applying the patchset:

ORABPEL-02118

Variant not found.
The variable "__loopCondition" is not declared in the current scope. All variables must be declared in the scope before being accessed. This was an internal error. The flow was not generated correctly by the BPEL compiler.

The audit trail will show the following message:

The transaction was rolled back. The work performed for bpel instance "xxx" was rolled back to the previous dehydration point, but the audit trail has been saved. You can recover the instance from the recovery console by resubmitting the callback message or activity for execution.

It seems SOA Suite uses an internal variable to count the number of times a loop is executed. Probably, this variable is not initialized when using a SOA Suite 11g version predating PS3 and thus results in the error.

There are two solutions to this:

• Validate there are no running instances that execute a While loop while patching your environment;
• If not, use the patch as indicated in patch reference 1451018.1 at the Oracle Support Site.

After applying the patch and restarting SOA Suite you will notice the following log entry indicating the loop count exception is handled by SOA Suite:

<Warning> <oracle.soa.bpel.engine> <BEA-000000> <Handling Exception on setting __loopCondition. This is expected for in-flight instances created before SOA upgrade from PS3 or older versions. 

Default Human Worklist Application and OWSM

The out-of-the-box Human Worklist Application is configured to use the oracle/no_authentication_service_policy policy of Oracle Web Services Manager (OWSM). This policy became available in later patchsets, but isn't shipped with SOA Suite and OWSM PS2. Without updating your OWSM policy store you'll see the following error when logging into the Human Worklist Application after applying PS5:

An error occurred for port: {http://xmlns.oracle.com/bpel/services/IdentityService} IdentityServicePort: oracle.fabric.common.PolicyEnforcementException: PolicySet Invalid: WSM-06162 PolicyReference The policy referenced by URI "oracle/no_authentication_service_policy" could not be retrieved

This can be fixed by updating the OWSM policies using the upgradeWSMPolicyRepository() command. This is documented in Upgrading the Oracle WSM Policies in the Repository. Make sure the Managed (or Admin) Server on which the OWSM PM application is deployed is running. Otherwise you'll see an error indicating that an MBean that is used for the policy upgrade cannot be reached.

See the Oracle Fusion Middleware Security and Administrator’s Guide for Web Services 11g Release 1 (11.1.1.6) for more information on OWSM and its policies.

From the Trenches 2 | Patching OSB and SOA Suite to PS5

In my previous blog I talked about a recent upgrade from Oracle Fusion Middleware 11g PS2 to 11g PS5. This blog continues with two post-installation steps that were required to complete the upgrade.

Patching Oracle B2B for ebMS-based services

In this particular project we implemented ebMS-based services using Oracle B2B and Oracle Service Bus 11g. Besides "plain" SOAP Web Services, ebMS is part of the Dutch government standards to exchange messages and expose services between organizations in the public sector. You can read more about implementing ebMS-based services using Oracle B2B, Oracle Service Bus and Oracle SOA Suite in this presentation.

The ebMS standard makes extensive use of SOAP headers to facilitate features such as guaranteed delivery and to avoid duplicate messages. The following snippet shows part of an ebMS message header.

One of the identifiers used in the ebMS message exchange is the manifest id. According to the ebMS specification maintained by OASIS this needs to be XML NCName type. This type has some restrictions; for example that its values cannot start with a number. In Oracle B2B 11g PS2 the manifest id value is prefixed with the text oracle. This prefix is removed in 11g PS5 resulting in the following error from the B2B trading partner at runtime:

09:06:00 Local Listener(8914) Result: "Error" "Fault sent:<SOAP:Fault><faultcode>SOAP:Client</faultcode><faultstring>org.xml.sax.SAXParseException: cvc-datatype-valid.1.2.1: '0A1A1A1A1A1A1A1A1A1A1A1A1A1A1A1A' is not a valid value for 'NCName'.</faultstring></SOAP:Fault>"

Luckily there is an easy-to-apply patch that solves this problem; see article 1497168.1 on Oracle Support. After applying the patch, the manifest id is prefixed with a text value again.

Changing namespaces in WSDLs and XSDs of JAX-WS Web Services

The environment that was patched contains several Java applications running on WebLogic Server. These applications expose Web Services using JAX-WS. A meet-in-the-middle approach was used to create them: the business logic implemented in Stateless Session Beans and JPA (EclipseLink) is integrated with the Java classes generated from the predesigned WSDLs and XSDs.

Depending on the developer that created the Web Service, deployment descriptors such as webservices.xml and weblogic-webservices.xml were added to the application. Descriptors are used for configuration, overriding default settings, and adding metadata. For Web Services this can be the endpoint, port configuration, linkage of the Web Service to EJB components, and so on. When deployed, the WSDL location of Web Services is listed in the WebLogic Console and the WSDL can be retrieved at runtime.

After the patch we noticed that these artifacts weren't identical to the original WSDLs and XSDs. More specifically, the namespaces of the XSD elements in the request and response message definitions were changed to the namespace of the service itself. At runtime however, the service accepted requests and responses as defined by the original contract. This makes it difficult to test these Web Services using clients that inspect the runtime WSDL; for example when creating a default project in soapUI.

This issue was resolved by removing the webservices.xml and weblogic-webservices.xml deployment descriptors from the Java archive and redeploying the Web Services to WebLogic Server. The WSDL that can be retrieved at runtime matches the original designed WSDL again.

From the Trenches | Patching OSB and SOA Suite to PS5

Recently I was involved in an Oracle Fusion Middleware upgrade from 11g PS2 to 11g PS5 with Jacco Landlust, Aiman Salama, and Jens Peters. The environment that was patched consists of the following domains:

• Java domain running Java/JEE applications;
• IDM domain running identity management components including OID;
• SOA domain running Oracle Service Bus and Oracle SOA Suite. 

The domains consist of several Managed Servers in a single-node cluster configuration. OSB and SOA Suite both run in their own Managed Server.

There are plenty of excellent blogs that discuss the infrastructure and middleware side of such an upgrade. This blogs contains some things we encountered from the application side of things. More specific, the SOA composites and OSB projects.

Rebuild custom Java classes and JAR files in the SOA extension library

You can add custom Java classes and JAR files to SOA Suite that are used by your SOA composites. The SOA extension library for adding extension classes and JARs is available in the $ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1 directory. For example, an extension can be used to add a custom fault handler.

After applying the patchset you need to rebuild and package the JAR files by running Ant in the $ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1 directory:

$ORACLE_HOME/soa/modules/oracle.soa.ext_11.1.1>ant
Buildfile: build.xml

create-manifest-jar:
     [echo] Creating oracle.soa.ext at $ORACLE_HOME/soa
/modules/oracle.soa.ext_11.1.1/oracle.soa.ext.jar :$ORACLE_HOME/soa
/modules/oracle.soa.ext_11.1.1/MyCustomFaultHandler.jar;$ORACLE_HOME/soa
/modules/oracle.soa.ext_11.1.1/classes
      [jar] Updating jar: $ORACLE_HOME/soa
/modules/oracle.soa.ext_11.1.1/oracle.soa.ext.jar

BUILD SUCCESSFUL
Total time: 0 seconds 

Reconfiguring OWSM policies

The Oracle Service Bus is used to expose services to the outside world in this environment. These services are secured using Oracle Web Services Manager (OWSM). Services can only be invoked over SSL and the SOAP requests require a WS-Security token for authentication. Among others, these services are invoked by SOA composites that run on SOA Suite and a Silverlight/.NET Portal application. The SOA composites apply the oracle/wss_username_token_over_ssl_client_policy policy to enforce SSL and add the required WSS token.

Due to security integration issues between the Silverlight/.NET Portal and the Oracle Service Bus the service provider doesn't include a timestamp on the transport layer (SSL). The include timestamp setting of the oracle/wss_username_token_over_ssl_client_policy policy was therefore disabled.

After the upgrade we noticed errors in the log files when the SOA composites invoked the Web Services exposed by the OSB: the SSL endpoints of the Web Services could not be reached. Although it seemed the Web Service was actually invoked, and the same SSL endpoint was reachable from a browser. To verify what went wrong we enforced the security/logging assertions of the policy. This causes the outbound SOAP call to be logged to the OWSM logfile: once before applying the policy (without WS-Security tokens) and once after applying the policy (message including the WS-Security tokens). The log showed that the SOAP request contained the correct WSS headers, and that a valid SOAP response was returned by the Web Service. So the Web Service call actually took place. However, the OWSM client policy returned an error that the SSL endpoint was unreachable. It seemed the timestamp setting was activated again by the patch causing a validation error on transport level. Disabling the include timestamp setting fixed the problem.

See Securing Heterogeneous Systems Using Oracle Web Services Manager on Slideshare for more info on this subject.

Using the default SOA Suite XSDs from MDS

SOA Suite supplies out-of-the-box XSDs for interacting with Human Workflow, using Sensors, catch BPEL-specific faults, and so on. These XSDs are preseeded in MDS: both in the MDS schema created by RCU and in JDeveloper after installing the SOA extension in $JDEVELOPER/jdeveloper/integration/seed/soa/shared. Applying the patch will upgrade some of these XSDs. It is therefore important to refer to those XSDs in your SOA composites using MDS. Don't copy and package these XSDs locally inside your composites. Doing so results in errors since SOA Suite detects discrepancies between the packaged SOA Suite XSDs (old patchset), and the same XSDs in MDS (that are updated by applying the patch).

Invoking the TaskService.acquireTask operation 

The Portal application retrieves Human Tasks by invoking the out-of-the-box SOA Suite APIs. When tasks are acquired by users, authentication information needs to be passed to the TaskService.acquireTask operation. A required token is obtained by invoking the TaskQueryService.authenticate operation. The SOAP request that is generated by the Portal includes both the user and onBehalfOfUser as part of the authentication information. While this worked in PS2, in PS5 this resulted in an authentication error indicating that the user had too few privileges to authenticate on behalf of another user. The issue is resolved by removing the onBehalfOfUser element in the SOAP request. Since the SOA Suite APIs are exposed through the OSB in this environment we could alter the request pipeline of the OSB routing flow to delete this element as a temporary solution. A better solution is to upgrade the Portal so the SOAP request doesn't include the onBehalfOfUser element altogether.

Workflow Notification settings

The SOA composites use the Workflow Notification capabilities to send (actionable) emails and email alerts for Human Worfklow. After applying the patch the following error occurs:


<Feb 7, 2013 12:04:38 PM CET> <Warning> <oracle.soa.services.notification> <BEA-000000> <<.> With the current setting, only Email notifications will be sent; Notifications via voice, SMS or IM will not be sent. If you would like to enable them, please configure corresponding sdpmessaging driver. Then modify the accounts and set NotificationMode attribute to ALL in workflow-notification-config.xml> 
<Feb 7, 2013 12:04:39 PM CET> <Error> <oracle.soa.services.notification> <BEA-000000> <<.> Incorrect incoming Notification Configuration.
Incorrect Incoming Configuration : AccountName : Default.
The AccountName in workflow-config.xml should be one of the names used in workflow-notification-config.xml.

ORABPEL-31031

Incorrect incoming Notification Configuration.
Incorrect Incoming Configuration : AccountName : Default.
The AccountName in workflow-config.xml should be one of the names used in workflow-notification-config.xml.

Reconfigure the Workflow Notification settings in Enterprise Manager to solve this issue.

Summary

All in all, the Oracle Fusion Middleware upgrade of all domains was done in a few days. We had some excellent help from Oracle Support for one issue (config.xml with an incorrect Coherence configuration after the patching) that was quickly resolved. Just as any project, good preparation is half the battle. Make sure to read and follow the Oracle patching guides and use the tips & tricks from the available blogs. Be sure to backup the environment, including the OFM database schema's such as MDS and SOAINFRA, and test the upgrade on a production look-a-like test environment. Even if all consoles such as the Service Bus Console and Enterprise Manager work correctly, also inspect the log files for any error. Finally, in case you have longer running SOA composites, make sure you have a testset of open and running composite instance before patching the environment for regression testing.

"Start Small, Grow Fast" in Top 10 articles for architects (2012)

The whitepaper Start Small, Grow Fast by Demed L’Her, Edwin Biemond, and Ronald van Luttikhuizen ranks 3rd in the Top 10 most popular OTN articles for architects (2012). The full Top 10 including links to these articles is listed here.

The whitepaper explains a set of pragmatic best practices for deploying a simple and sound SOA footprint that can grow with business demand. The paper contains details about administrative considerations, infrastructure considerations, development considerations, and architectural considerations. 

You can find a companion checklist that summarizes the Oracle SOA Suite best practices in a previous blog.

SCA Composites: Java or BPEL?

Oracle SOA Suite offers different technologies to implement logic:

• OSB to expose services and to create composite services
• BPEL for process and orchestration logic and for composite services
• Mediator to route and transform messages
• BPMN for process logic
• Human Task Service for human interaction
• Business Rules for (reusable) business logic outside your components
• Spring Context for programming logic in Java

In our project we were moving a composite service from OSB to BPEL because the code became too complex and too difficult to understand and maintain in the OSB flow. The service consisted of numerous calls to other services, loops, several transformations and relatively complex XPath expressions and a java call-out. 

I did not want to put a java call out in my BPEL process, I rather have the Java code as a first class citizen in my sca composite. This way it is clear that there is java code in the composite and it can be traced in the console. 

Moving the Java from OSB to the Spring context was very easy. 

• First I removed all the static methods and refactored the Java class into a proper bean
• Then I renamed the methods, so I did not have overloaded operations in the web service and ran the unit tests again
• I created a Spring Context as described in the Oracle Documentation here
• Finally I wired the BPEL component to the SCA context
• I created assign and invoke activities in BPEL
• I ran the deployment scripts that I created for SCA composites

This whole exercise took me about 10 minutes. Granted it was a very simple Java class. There are numerous advantages of Java code: I can test the Java class without deploying it. Refactoring of methods, variables etc support in the IDE (JDeveloper) makes changing the Java code very easy.

I need to move more BPEL logic into Java code. This will improve my productivity, increases the testability of the service and makes it much easier to read, compared to the combination of XSLT transformations with XPath and assign statements. I tweeted about this notion and Demed L'Her warned about the lack of runtime visibility of Java code.  

Java in SCA Spring context versus BPEL

Let's compare different requirements for both the implementation of the SCA component in Java or in BPEL:

Feature	Java	BPEL	Explanation
Productivity	High	Medium	Refactoring is not supported in BPEL, if you want to change the name or namespace of the process, this is a lot of work. There is code completion for XPath in BPEL, this increases productivity considerably.
Maintainability	High	Medium	XML code is hard to read, the visual designer hides the implementation of assigns and transformations.
Testability	High	Low	BPEL can only be tested after deployment, Java can be tested outside the container.
Runtime visibility	Low	High	BPEL has flow and audit trail, so you can see exactly what happened in your process
Recoverability	Low	High	BPEL has a fault management framework that allows you to recover activities
Configurability	High	High	Configuration plans and properties for both SCA Spring Context and BPEL
Calling services	High	High	SCA offers easy access to services, no matter what the implementation of the component is, both Java and BPEL can easily call services

Unfortunately there is no single good answer for all your problems. It really depends on the service and the logic that you need. In other words, it depends on the requirements you have with regards to functionality, visibility and recoverability whether OSB, BPEL or Java in a Spring context is the best solution for your composite service. But the SCA context makes calling services and thus creating composite services in Java a lot easier than it used to be.

Of course, the evaluation of the requirements is subjective: I have been programming Java since 1997 and am very used to the testing and refactoring capabilities Java tools offer. People with a more declarative coding background might prefer BPEL for that reason. I am very interested in other peoples' experiences with these aspects.