Thursday
Dec192013

WebCenter Portal an Agile Approach (Continuous Integration) 

To recap from my prior post, we have our teams working within their own JDeveloper Applications testing their code locally through the ide built in tools. Alone this can produce “works on my machine” syndrome, so how do we eliminate this syndrome? Through Continuous Integration where we fail fast. I am not going to explain the merits or each nuance to implement CI in this post, I will be showing the project setup and how to get the applications building and running for our Acme Portal Project using Hudson and working with their dependent applications.
A quick explanation of Continuous Integration (CI) it is a software development practice where members of a team integrate their work frequently leading to multiple integrations per day, in a automated build, including running tests to detect integration errors as quickly as possible, verifying each team member’s contribution and integration quickly in a fail fast manner for the entire portal application.
I want to also comment that Hudson Server can be used as a Deployment engine too, not covered in this post but planned for future posts.
Below is the end result of our applications building is a screenshot of our now healthy Portal Project with all the applications (Hudson Projects) building and integrating amongst themselves.

 

 

I want to also comment that Hudson Server can be used as a Deployment engine too, not covered in this post but planned for future posts.
Below is the end result of our applications building is a screenshot of our now healthy Portal Project with all the applications (Hudson Projects) building and integrating amongst themselves.

The above picture is the project dependency tree; I will go into detail on how I have them setup to build and their dependencies. The order in which I describe them is the order that each application is built when starting from scratch and is the path of the dependency tree.  *** Be carful naming ambiguity ***, 1 JDeveloper application maps to 1 Hudson Project and a JDeveloper application can have multiple JDeveloper projects encapsulated, which will just cause more ant tasks in multiple Ant files getting called within the 1 Hudson Project.

1. libs – this project is our repository of third party libraries used in the applications, since JDeverloper and ojdeploy is using Ant I will not involve maven for dependency management. New ADF Oracle has started supplying maven dependencies but this is not the case for WebCenter yet. An example of a third party jar in our project is the commons-lang3-3.1.jar. This configuration says to watch for added jars and if updated, download and then trigger the first lowest application on dependency tree to start to build.

Configuration settings:

  • Job Name: libs
  • Repository: svn/portal/trunk/libs   [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build other jobs: CommonsProject [Commons is the lowest application that needs this application] 
  • Block build when downstream job is building:true
  • Block build when upstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

2. CommonsProject – this project is triggered when new code is checked in or when a new jar is added to the library project.

Configuration settings:

  • Job Name: CommonsProject
  • Repository: svn/portal/trunk/CommonsProject  [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build after other jobs are built: libs
  • Build other jobs: BackendEndProject [this is the above the dependency tree for our projects] 
  • Build after other jobs are built:libs
  • Block build when downstream job is building:true
  • Block build when upstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

3. BackendEndProject – this project is triggered when new code is checked in or when the CommonsProject is built.

Conifguration setting:

  • Job Name: BackendEndProject
  • Repository: svn/portal/trunk/ BackendEndProject [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build other jobs: ComponentsProject [this is the above the dependency tree for our projects] 
  • Build after other jobs are built: CommonsProject
  • Block build when downstream job is building:true
  • Block build when upstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

4. ComponentsProject– this project is triggered when new code is checked in or when the BackendEndProject is built.

Configuration settings:

  • Job Name: ComponentsProject
  • Repository: svn/portal/trunk/ ComponentsProject [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build after other jobs are built: BackendEndProject
  • Build other jobs: AcmeProject [this is the top Parent that puts all the projects together for the Portal] 
  • Block build when downstream job is building:true
  • Block build when upstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

5. AcmePortal– this project is triggered when new code is checked in or when the ComponentsProject is built.

Configuration settings:

  • Job Name: AcmePortal
  • Repository: svn/portal/trunk/ AcmePortal [I am set up to build trunk]
  • Pool SCM: * * * * *  [check every minute]
  • Build after other jobs are built: ComponentsProject
  • Block build when downstream job is building:true
  • Clean workspace before build:true [no dirty leftover files]

The above configurations ensure that our dependencies are harmonized and that our code will fail fast when they are not, unit testing and Code Quality Metrics are generated for management and team members to review.

The above picture showing a failed build touches on this fail fast paradigm that I have eluded too in this post. This practice when done correctly encourages frequent check-ins to ensure your code is working with others, it also fosters when managed correctly a group think/mentoring when a failure occurs where the team addresses the issues from the broken build. 

 

The above picture is to demonstrate one of the type of reports that can be available to the team and management.  Unit testing and reporting is an important topic and will have its own future post devoted to it.

 

 

 

Sunday
Oct272013

WebCenter Portal an Agile Approach

Introduction

Let’s first lay out the initial vision for our Ace Portal team. We just parachuted into the Acme Company who recently purchased Oracle WebCenter Portal. They know they need a Portal since Oracle packaged it with their Enterprise Corporate database purchase. The first step to our mission is to create an initial setup of a Portal in an agile development environment. This allows us to gather requirements, deploy small sets of Portlets in a timely fashion, and effectively allow the client to provide feedback throughout the process. A note to all Agile purists (if there is such a thing): this approach may not follow a traditional Agile methodology, however this is how I've successfully deployed WebCenter Portal projects in the past.

Our team will consist of a multifaceted talented set of team members. Titles and skill sets are as follows:

  • User Experience (UX) members: ADF Skins developer with CSS3, ADF template, and WCAG/508/ADA experience.
  • Middle-tier developers: JSF/ADF components and basic Java bean development experience.
  • Back-end developers: ADF business components, database and services skills.
  • Content Management Dev/Administrator: A limited license is usually given by Oracle to WCC, however the company might already have an existing CMS in place (i.e. Documentum).
  • Administrator Software Configuration Management (SCM): WebCenter Portal Administrator, Oracle Metadata Repository (MDS), Jenkins and ojdeploy Ant task experience.

Now we need to setup our development environment with a project layout that will allow our team to work independently while still deploying on an integrated domain. We must also remember that our Acme client may not have the necessary portal knowledge to effectively communicate the needs of the project’s look-and-feel and portlet details. Therefore, our development team will be deploying various versions in order to receive useful feedback from the client. The client has hinted about having an application that will work with this new database they just bought from Oracle and something like a stock ticker for the CFO. Project Configuration, Continuous Integration, and Build & Deploy systems are needed simultaneously. I like to refer to this group as "The Agile Landscape":

Project Configuration

Let’s get started by splitting out projects into our areas of concern. Guess what? They each match up perfectly with our team setup (this is by design).

Project Hierarchy Diagram

Project Descriptions

UX_Project: [JDeveloper ADF Skin] skins, javascript (minimal if needed) and Sprites (images) - images as we know are frowned upon. Note: I am not sure why the ADF Skin Editor cannot run inside JDeveloper 11.1.1.7. JDeveloper 11.1.2 * is required currently.
Component_Project: [JDeveloper Fusion Web Application ADF] This project will consist of taskflows and simple Java beans. This is where the controller layer lies for our portlets, and also includes some business logic. The secret sauce cannot be given out - each project is different. I like to try and keep the bounded task flows encapsulated into their own flow logic. The approach is to pass all of the parameters into the taskflow - even requests and session values. At first it might be difficult to figure out what logic can be reused across these taskflows (let alone the entire corporate landscape). Keep in mind, however, that as we grow our portlets and taskflows - they will naturally group into categories which we can collect in multiple component projects after multiple iterations.
Commons_Project: [JDeveloper Generic Application] Having a placeholder encourages re-use so I have created a commons project. Note: This is not required for every project.
BackEnd_Project: [JDeveloper Fusion Web Application ADF] This project will house the data components for the databases and web services. This can also include a custom content repository or a WebCenter Content connection. To start I created a simple POJO data-bound control.
Master_Project: [JDeveloper WebCenter Portal Framework Application Project] This will be the collection of every other project as shared resource jars. MDS Configurations and Site Resources will be included here (i.e. navigation, security, site templates, etc.). We will name this Master WebCenter Framework Portal Project: ‘AcmePortal’. This is instrumental for managing site resources that can be updated without a complete redeploy of the entire Portal.

JDeveloper Project Screenshots

UX Project

Components Project

Commons Project

BackEnd Project

Master Project

Conclusion

This is a high-level walkthrough of the layout for our projects and assets. This allows our team to work simultaneously in an agile environment to create a portal and answer the business needs for the Acme Company. It is absolutely imperative that these separate projects are continuously growing and dependencies are consistently updated in order to encourage a fail-fast integration approach. Stay tuned for my next post which will describe how to seamlessly build and integrate all of these projects together. The image below displays the simple Acme Portal using a single portlet on the home page to show each piece working together.
Tuesday
Oct012013

OOW2013

 

 

 

WCP = Single pane of glass for end users.
1. Responsive design templates, and ability to create specific templates for targeted mobile device page variant is key for targeting.

WCC = mobile
1. Has mobile applications for iPhone and android.
2. New responsive traditional web UI to edit documents.
3. Ability to have a more personal content management than can share, meaning very smooth workflow and collaboration of content before going live.
4. Web UI looks like dropbox, oracle now has document service in the cloud probably reason for Dropbox look.
5. On premise WCC syncs with the cloud, nice idea to do on premise then when approved deploy to cloud service for sharing let oracle handle the load i.e. CDN for your documents.

ADF , Meta Data Service MDS*, customizations and extensions
1. Layered customizations
2. Can do personalizations for end user.
3. Repository = File classpath or DB
4. Context gets setup to get from MDS get merged XML to display to user.
5. Patch safe since customizations are separate from base xml
6. Sandbox for customizations fork of the main line i.e context were others can hare too.
7. MDS labels to publish a set of changes to production (customization set)
8. Good idea for layers: Global,Site,Role,User,country,organization,internal/external,job role.
9. MDS ties to ADF resource bundles for internationalization.
10. DTRT api to allow run time customizations.

Building ADF team the journey
1.bit.ly/ADFTour
2.oracle.com/jdev
3.oracle fusion developer guide
4.oracle.com/usableapps. ***

Team roles:
Adf team lead
Add developer
Skin developer
Database developer
Java expert
JSF expert

Types of teams due to adf shared libraries.
UI teams (mobile)
Services
Soa layer

Cloud Developer Services (big push for oracle)
Make sure ADFLogger is being used.
support note 971256.1 to get add source code.

Reuse:
1. Create base classes
2. Develop templates
3. Build declarative components
4. Distribute via ADF libraries
5. Agree upon - and enforce naming conventions

Adf YouTube channel:YouTube.com/user/ADFInsiderEssentials

Architecture questions:
Team size,skill capability
One vs multiple appa
One vs multi-page apps
Level of software reuse
Sequential vs parallel development
Application customization
Legacy application modernization
Integrating mobile

Webcenter Portal direction:
Multi-Channel,Consumerization,Cloud -> road map
Focus- Worker Productivity and Mobility.

Targeting devices is the key push for webcenter portal.
Native application through rest services.

ADF adaptive thoughts:
1.Simplicity vs flexibility the conundrum for ADF.
2. El expression to access passed in variables from the bounded taskflow to generify page and BC components like names of data controls etc...
3. DynamicComponent is out of the box dynamic component allows for CRUD without having to do all the messy coding works with many different components through tree binding like a drop down box. Attribute model is key DC to show hide read only based on value of a field business logic component is the main object for that.
4. oracle.job.client.ELEnvInfoProvider and EL to resolve the connection have a bounded taskflow pass it in blog articles on this at groundside blog

Adf best practices:
1. Pageflow and Page templates always use them.
2.Extend base classes def base classes not needed too, good for logging and transaction times for BC components.
3. Always define facets for developer to add too.
4.Declarative components are nice to extend the functionality of a common reused components.
5. Example date component that is declarative then changing common date changed in one place because its declarative instead of the base component and changing the format in 90 places.
6. Always work with the grain of the framework. Going against the framework you will fail figure out how it is done.
7. Have to work with version control inside JDeveloper do to all the files that go with making one change.
8. 11.2.* does not have git support
9. Without maven check in shared libraries in approved repository of svn for different component developers to checkout and reference in their workspace.
10. ADFLogger runtime can be changed.
11. Always start with creating build structure and building of the modularizations and automate the building or you will FAIL .

Scale WCP
1. Big hit with numerous adf components on a page.
2. Jascript partitioning.
3. Multiple ADM take up database connection, adm does not release connection it has its own pool consider webservices with good SLA
4. Definitely need to tune webcenter portal out of box is no good.
5. Client_state_max_tokens lower
6.MDS cache needs to be increased usually purge MDS too.
7. CDN for adf http://www.ateam-oracle.com/cdn-support-in-adf-faces-11-1-1-6/
8. Oracle OATS for testing add


'My Take' Portal has to be more than a view in a browser has to evolve to a single pane that is contextual and device aware. The desktop is only one of many devices phone,tablets etc...(TV).

My own quick notes that I want to go back too.
Links
Bit.ly/jsf-lifecycle

https://groups.google.com/forum/?hl=en#!forum/adf-methodology

https://blogs.oracle.com/jdeveloperpm/entry/adf_faces_stencils_for_visio_available_on_samplecode

https://blogs.oracle.com/onesizedoesntfitall/entry/adf_naming_and_project_layout

Blogs.oracle.com/ground side

 

Wednesday
Sep252013

Links

https://www.dropbox.com/s/92cfcfyfqxygpgo/HOL10178-Mobile%20Access%20Management%20and%20API%20Security.pdf
https://www.dropbox.com/s/u0tu9o0roj07dh4/HOL10178-Mobile%20Access%20Management%20and%20API%20Security-PPT.pdf

http://www.eaipatterns.com

https://plus.google.com/+Geekboots/posts/Ez7vBHb17Lj

 

Sunday
Sep222013

OOW

https://blogs.oracle.com/jdeveloperpm/entry/adf_faces_stencils_for_visio_available_on_samplecode