Tuesday, October 29, 2013

WebCenter Portal - Sitemap Customization

Sitemap customization within WebCenter Portal is a lot easier than it may seem.

Within web.xml the sitemap servlet is defined as per below.


Conveniently, there is also a method available to retrieve the default sitemap. This sitemap is generated from the default-navigation-model.xml.

import oracle.webcenter.portalframework.sitestructure.preference.PortalPreferences;

String siteMap = "";
siteMap = PortalPreferences.getInstance().getSiteMap();

As such all you need to do is perform a find and replace within the siteMap string in order to manipulate your result or return your own customized sitemap from the servlet.

A sample of the full servlet is below:

package test_portal.portal.servlet;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;

import oracle.webcenter.portalframework.sitestructure.preference.PortalPreferences;

public class SiteMapServlet extends HttpServlet {
 
    transient ServletConfig config = null;

    public void init(ServletConfig config) throws ServletException {
      this.config = config;
      super.init(config);
    }

    public void doGet(javax.servlet.http.HttpServletRequest httpRequest, javax.servlet.http.HttpServletResponse httpResponse) throws IOException {

        httpResponse.setContentType("text/xml");

        PrintWriter out = httpResponse.getWriter();
        String siteMap = "";
        siteMap = PortalPreferences.getInstance().getSiteMap();
        siteMap = siteMap.replaceAll("/faces/testNav","http://sample.com");
        siteMap = siteMap.replaceAll("/faces/home","http://sample.com/");
        siteMap = siteMap.replaceAll("\\?wcnav.model=%2Foracle%2Fwebcenter%2Fportalapp%2Fnavigations%2Fdefault-navigation-model","");
        siteMap = siteMap.replaceAll("</loc>","</loc> \r <changefreq>weekly</changefreq>");

        out.println(siteMap);

        out.close();

    }
 
}




Thursday, February 21, 2013

Side by Side Deployments (Rolling/Hot/InPlace Deployments)

One of the great features of ADF/Weblogic is side by side deployments. This allows you to deploy two different versions of an application to a Weblogic server without the need for an outage. Weblogic is smart enough deal with current and new session. Once the new version of the application has been deployed to the server the old version of the application set in to "Retired" status and the new version is set to "Active". The retired version of the application maintains any active sessions until they end (also has the option to expire all sessions immediately or after a set time period). Whilst the new active version of the application handles all the new sessions, this is quite a cool feature. I've used this a fair bit and it seems to work quite well. This only catch is if you are a deploying a large ear file the response times of the server do suffer.

Anyway, here is how you do it.

Firstly create a two test applications.

Create a MANIFEST.MF file and paste the following details inside. Take note of the Archive-Version, this is the version number that weblogic looks for when it decides to retire or promote the new application. 


You will need to create a new deployment profile.


Then define your new manifest file.


Then do the same as above but increment the Archive Version and do the above two steps to the second application.


In order to test that the side by side deployment worked. Deploy the first application and it should appear as 'Active' in the weblogic console, then deploy the second application and the first application should get set to 'Retired' and the new application will be set to 'Active'. 

To ensure that you don't have an outage you can test the site with a load testing too such as LoadUI as I did below. You can see an increase in response time when the second application is being deployed. In reality, it is Oracle's recommendation that you have the Admin Server running on a separate machine to your managed servers. So when you do a side by side deployment in "theory" you shouldn't see an increase in response times as you can in the below test.



Wednesday, February 20, 2013

Modifying Web Service Endpoint at Runtime

Recently, we came across an issue where we had to modify the end points of several previously generated web service proxies for a application with the requirement to run on a number of different environments.

The initial thought was that we could do this through an ANT script. However, this became very messing, very fast. So after a bit of think I realised the endpoint was in the request and the request could be modified.

Hence the below code refers the to the ENDPOINT_ADDRESS_PROPERTY property key for the request. Allowing you to modify the endpoint at run time before the request is sent. Opening the door to modify the endpoint to a string specified within a database or property file.


 TestWebService webservice = testWebServiceServiceagent.getTestWebserviceSOAPHTTPEndpoint();  ((BindingProvider)webservice).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "new end point");

Friday, September 28, 2012

ADF - Removing the Application Name from URL (Weblogic)

In order to remove the root context of an ADF or WebCenter application or the application name from the URL, it's quite a simple Weblogic configuration change.

Change the root context of an application can be done from via changing the application.xml. However, this can be quite an involved change if you are using a continuous intergration server such as Hudson or Jenkins as you will need to modify the build scripts to decompile the .ear copy in the new application.xml and then recompile the .ear. 

You will be happy to know Oracle have made a simple yet not well documented fix for this. As per the instructions below: 

1) Go to http://127.0.0.1:7101/console

2) Environment > Servers > DefaultServer(admin) > Protocols Tab > HTTP Tab

3) Modify the "Default WebApp Context Root" to /application_name


4) Hit Save

5) Go to Deployments

6) Select FMW Welcome Application - Undeploy (Check the box and click delete)

7) Restart Weblogic Server.

Go to http://127.0.0.1:7101/ or the home page of your application http://127.0.0.1:7101/faces/home.jspx and your application should come up. 

If faces is also an issue, for you this can also be removed, with a little more effort and the use of a java filter.


WebCenter Portal - Linking Between Navigation Models

A navigation model in WebCenter is primarily used for the navigation and navigational structure of a WebCenter portal application  At a current clients site we ran into the issue of using multiple navigation models and linking to them without the context of another or the current navigation model.

After a lot of research and poking around with the framework I managed to figure out that WebCenter has an undocumented (I couldn't find the doco) method of allowing to you to provide the context of a navigation model through a query string in the URL. 

If you tried to go to a URL in WebCenter and you go to the below you URL you will be linked to the root level id called home in the default navigation model. As such if your refer to an id in another navigation model you will receive a 404 error. However, if add the location of the navigation model as a wcnav.model query string it seems to find it's navigation context.

Default Navigation Model: http://127.0.0.1:7101/testapp/faces/home
Test2 Navigation Model: http://127.0.0.1:7101/testapp/faces/home?wcnav.model=/oracle/webcenter/portalapp/navigations/test2_navigationModel1






This opens alot of doors in terms of WebCenters URLs. As with a little effort allows for bookmarkable, SEO friendly URLs.

Thursday, October 20, 2011

Using WebLogic Server Embedded LDAP

Recently, I've had the need to setup user authentication with webcenter and noticed that weblogic had it's own built in LDAP server. I didn't find my information around on the OTN or google about it so I thought I'd share what I learnt. Below is how to setup LDAP on a WLS and authenticate against it in Java.

Setting up Embedded LDAP on the Intergrated WLS


You will need to set the credential and confirm credential to a new password and check the Anonymous Bind Allowed check box. In this example we will use “welcome1”.

All the below methods can be used to interface with the WLS Embedded LDAP.

If you need to explore the WLS embedded LDAP directory structure you can download JXpolrer and use the following details.

Localhost Details:
Host: 127.0.0.1:7101
Base DN: dn=DefaultDomain
User DN: cn=Admin
Password: welcome1



Variables



private String ldapServer = "ldap://127.0.0.1:7101"; private String ldapPassword = "welcome1"; private String ldapDC = "DefaultDomain";

Change Password

public String changePassword(String username, String oldPassword, String newPassword, String confirmNewPassword) { if (oldPassword.equals(newPassword)) { System.out.println("new and old passwords match"); return "Your new password must be different from your old password."; } if (!newPassword.equals(confirmNewPassword)) { System.out.println("new password and confirmed password don't match"); return "Your new password must match your confirmed password."; } if (!isAuthenticated(username, oldPassword)) { System.out.println("old password was not authenticated"); return "Your old password is incorrect."; } String ldapUri = ldapServer; String admindn = "cn=Admin"; String admincred = ldapPassword; String usersContainer = "ou=people,ou=myrealm,dc=" + ldapDC; Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, ldapUri); env.put(Context.SECURITY_PRINCIPAL, admindn); env.put(Context.SECURITY_CREDENTIALS, admincred); try { InitialDirContext initialContext = new InitialDirContext(env); DirContext ctx = initialContext; ModificationItem[] mods = new ModificationItem[1]; Attribute mod0 = new BasicAttribute("userpassword", newPassword); mods[0] = new ModificationItem(DirContext.REPLACE_ATTRIBUTE, mod0); ctx.modifyAttributes("uid=" + username + "," + usersContainer, mods); ctx.close(); return "Password Changed!"; } catch (NamingException e) { System.out.println(e); return "Woops! Something went wrong!"; } }

Create User

public String createUser(String firstname, String lastname, String username, String password, String confirmPassword) { if (!password.equals(confirmPassword)) { return "Passwords do not match."; } String ldapUri = ldapServer; String admindn = "cn=Admin"; String admincred = ldapPassword; String usersContainer = "ou=people,ou=myrealm,dc=" + ldapDC; Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, ldapUri); env.put(Context.SECURITY_PRINCIPAL, admindn); env.put(Context.SECURITY_CREDENTIALS, admincred); try { DirContext ctx = new InitialDirContext(env); Attributes attrs = new BasicAttributes(true); Attribute objclass = new BasicAttribute("ObjectClass"); objclass.add("top"); objclass.add("inetorgperson"); objclass.add("wlsuser"); Attribute surname = new BasicAttribute("sn"); surname.add(lastname); Attribute givenname = new BasicAttribute("givenname"); givenname.add(firstname); Attribute cn = new BasicAttribute("cn"); cn.add(username); Attribute mail = new BasicAttribute("mail"); mail.add(username); Attribute name = new BasicAttribute("displayname"); name.add(firstname + " " + lastname); Attribute pwd = new BasicAttribute("userpassword"); pwd.add(password); attrs.put(objclass); attrs.put(mail); attrs.put(givenname); attrs.put(name); attrs.put(cn); attrs.put(surname); attrs.put(pwd); ctx.createSubcontext("uid=" + username + "," + usersContainer, attrs); ctx.close(); return "success"; } catch (NameAlreadyBoundException e) { System.out.println(e); return "User already exists."; } catch (NamingException e) { System.out.println(e); return "Woops! Something went wrong!"; } }

Reset Password

public String resetPassword(String username) { SecureRandom random = new SecureRandom(); String randomString = new BigInteger(130, random).toString(32); String newPassword = randomString.substring(0, 8); String ldapUri = ldapServer; String admindn = "cn=Admin"; String admincred = ldapPassword; String usersContainer = "ou=people,ou=myrealm,dc=" + ldapDC; Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, ldapUri); env.put(Context.SECURITY_PRINCIPAL, admindn); env.put(Context.SECURITY_CREDENTIALS, admincred); try { InitialDirContext initialContext = new InitialDirContext(env); DirContext ctx = initialContext; ModificationItem[] mods = new ModificationItem[1]; Attribute mod0 = new BasicAttribute("userpassword", newPassword); mods[0] = new ModificationItem(DirContext.REPLACE_ATTRIBUTE, mod0); ctx.modifyAttributes("uid=" + username + "," + usersContainer, mods); ctx.close(); return newPassword; } catch (NamingException e) { System.out.println(e); return ""; } }

Check Authenticated

public boolean isAuthenticated(String username, String password) { Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory"); env.put(Context.PROVIDER_URL, ldapServer); env.put(Context.SECURITY_AUTHENTICATION, "simple"); env.put(Context.SECURITY_PRINCIPAL, "uid=" + username + ",ou=people,ou=myrealm,dc=" + ldapDC); env.put(Context.SECURITY_CREDENTIALS, password); try{ DirContext ctx = new InitialDirContext(env); String authorised = ctx.AUTHORITATIVE; ctx.close(); return true; }catch(NamingException e){ System.out.println(e); return false; } }










Wednesday, October 19, 2011

Custom WebService Headers (DataControl and Proxy)


 I've recently stumbled across a situation where I have had the need to call a web service which required custom HTTP headers and noticed there wasn't a lot of information around on how to do this in ADF in regards to using Data Controls or a Web Service Proxy.
Below are the two snippets of code I used and a brief description of how to implement them.

1)      Simply copy and paste the below snippet of code into your class right before you call the webservice. (The below snippet of code adds two headers into the HTTP request.)


Map<String, Object> reqCtx = ((BindingProvider)iditInterface).getRequestContext(); Map<String, List> reqHttpHeader = (Map<String, List>)reqCtx.get(MessageContext.HTTP_REQUEST_HEADERS); if (null == reqHttpHeader) { reqHttpHeader = new Hashtable<String, List>(); } List userName = new ArrayList(); userName.add("header1Value"); reqHttpHeader.put("header1", header1Value); List password = new ArrayList(); password.add("header2Value "); reqHttpHeader.put("header2", header2Value); reqCtx.put(MessageContext.HTTP_REQUEST_HEADERS, reqHttpHeader);

In order to add additional HTTP headers to a web service call using a data control you must override the existing SOAPProvider class.

1)      Create a new SOAP Provider Class “MySOAPProvider”
2)      Use the below code to override the Provider class
3)      Override the existing references to the SOAPProvider in the DataBindings.


import javax.xml.soap.MimeHeaders; import javax.xml.soap.SOAPMessage; import oracle.adf.model.adapter.AdapterException; public class CustomSOAPProvider extends oracle.adfinternal.model.adapter.webservice.provider.soap.SOAPProvider{ public CustomSOAPProvider() { super(); } public void handleRequest(SOAPMessage soapMessage) throws AdapterException { MimeHeaders hd = soapMessage.getMimeHeaders(); hd.addHeader("[header1]", "[header1value]"); hd.addHeader("[header2]", "[header2value]"); super.handleRequest(soapMessage); } public void handleResponse(SOAPMessage soapMessage) throws AdapterException { super.handleResponse(soapMessage); } }