Dashboard > Tempo > Home > FAQ > View
Tempo Log In   View a printable version of the current page.
FAQ
Browse Space    
Added by Nicolas Modrzyk, last edited by Alex Boisvert on Jul 02, 2008  

FAQ

Implement a new Task Attachment Service

In the config directory, we have a tempo-tas.xml configuration file.
The interesting part being:

<bean id="tas.storageStrategy" class="org.intalio.tempo.workflow.tas.core.WDSStorageStrategy">

Where you can just switch the implementation to a new class.
The class has to implement the StorageStrategry interface.

Hide or Show action buttons in xforms-mananager depending on the user

When you create a task, you need to send in some task metadata, and according to the Task Manager Service wsdl, we have 4 different actions available by default.

<xsd:element name="claimAction" type="tns:accessControlType" maxOccurs="1" minOccurs="0"/> 
<xsd:element name="revokeAction" type="tns:accessControlType" maxOccurs="1" minOccurs="0"/> 
<xsd:element name="saveAction" type="tns:accessControlType" maxOccurs="1" minOccurs="0"/> 
<xsd:element name="completeAction" type="tns:accessControlType" maxOccurs="1" minOccurs="0"/>

Each of them is of type accessControlType, as defined:

<xsd:complexType name="accessControlType">
 <xsd:sequence>
  <xsd:element name="user" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
  <xsd:element name="role" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>  
  <xsd:element name="authorized" type="xsd:string" minOccurs="0" maxOccurs="1"/>
 </xsd:sequence>
</xsd:complexType>

If nothing is assigned to those accessControlType, the related action will be available, and thus the button displayed by default.
If an assignment is made, then the action will be available only if the user or role matches.

With Intalio

The related action in designer is simply to create an assignment in the data mapper, on the process task initiating the create-complete pattern.

Deploy and manage processes

You can read the Apache Ode page dedicated on deploying processes at the following URL:
http://ode.apache.org/management-api.html
It might be worth it to also read the BPEL Management API on the ODE website as well.

Once you have a running instance on your local machine:

  • the service for Instance Management can be accessed here.
  • the service for Process Management can be accessed here
  • and in general, other ODE services can be accessed here

Deploy new components

To deploy new components in tempo you can call the deploy service (if your local server is running) or simply copy components in the $SERVER/var/deploy folder of the tempo server.
For the demo created by the create_tomcat script, this gives a directory with the following structure:

.
|-- AbsenceRequest
|   |-- AbsenceRequest.pipa
|   |   `-- AbsenceRequest
|   |       `-- AbsenceRequest.pipa
|   `-- AbsenceRequest.xform
|       `-- AbsenceRequest
|           |-- AbsenceApproval.xform
|           |-- AbsenceApproval.xform.xsd
|           |-- AbsenceRequest.xform
|           |-- AbsenceRequest.xform.xsd
|           |-- Notification.xform
|           `-- Notification.xform.xsd

If the component is properly deployed, it will appear with a .deployed extension, like this:

|-- AbsenceRequest.deployed

It is also possible to copy a zip file.
The deploy service in tempo is working on a really similar model as the one used in Apache Ode. In fact, we are planning into merging both of them in the near future.

Deploy AbsenceRequest without Intalio|Designer

A workflow process mostly needs two set of deployment.

  • Deploy process on Ode: deploy a BPEL process on Ode, by just copying the process files in the Ode deployment folder.
  • Deploy forms and pipa on Tempo: deploys the workflow forms, and the workflow PIPA tasks on tempo, by copying the files in tempo deployment folder.

Most of it has been described in previous FAQs, let's just review the PIPA descriptor:

# AbsenceRequest PIPA Task Descriptor
task-description=Examples - Absence Request
task-role-owners=examples\\employee
formURI=/AbsenceRequest/AbsenceRequest.xform
formNamespace=http://www.intalio.com/workflow/forms/AbsenceRequest/AbsenceRequest
processEndpoint=http://localhost:8080/ode/processes/AbsenceRequest/Employee_To_AbsenceRequest
userProcessInitSOAPAction=http://www.example.com/AbsenceRequest/Employee_To_AbsenceRequest/Employee_To_AbsenceRequest_PortType/Receive_Absence_Request

The most important attribute are:

  • task-description: is the title the PIPA will be used to show itself in, for example, the UI-FW processes list
  • task-role-owners: along with its sibling user-owners, is a comma-separated list of owners for the task. The task will be shown in the related people list.
  • formURI: is the full, or relative URL where the form can be found. This goes along the form manager configuration.
  • processEndpoing: is the axis service that will be called to start the process

Access forms directly

There is a way to call the forms directly, by creating a URL based on the following set of rules:

  • The base url of the server

    http://localhost:8080

  • The handler for the form

    /xFormsManager/init or
    /xFormsManager/act or
    /xFormsManager/notification

  • Then a few parameters:
    • The id of the task the form is attached to:

      id=cc29fd05-9494-4f90-b8dc-eb24c13a0bdb

    • The Type of the task:

      type=PIPATask or
      type=Notification or
      type=PATask

    • The URL of the form, as it has been deployed

      url=/AbsenceRequestAbsenceRequest.xform

    • A participant token

      token=...

This gives something like:

Sample URL(Right Click me)

Integrate with an LDAP server

You need to edit securityConfig.xml, comment out the SimpleSecurityProvider and uncomment the LDAPSecurityProvider. Then you need to edit ldap.properties according to your LDAP server.

The location of ldap.properties is configurable in the securityConfig.xml file. You can therefore place the properties file anywhere.

You can test authentication/authorization by using the Browser class and this script,

 
#!/bin/sh
CP=lib/tempo-security-5.1.0.14.jar
CP=$CP:lib/spring-1.2.5.jar
CP=$CP:lib/log4j-1.2.8.jar
CP=$CP:lib/commons-logging-1.0.4.jar
CP=$CP:.
java -cp $CP org.intalio.tempo.security.util.Browser -config securityConfig.xml "$@"

The way to test with the Browser is to try something like:

*java ... org.intalio.tempo.security.util.Browser -config myConfig.xml -roles*
=> should list all roles
*java ... org.intalio.tempo.security.util.Browser -config myConfig.xml -user MyUser*
=> should display user properties and roles
*java ... org.intalio.tempo.security.util.Browser -config myConfig.xml -user MyUser  -password XXXX*
=> should display whether authentication works for a given user

Pull Users and roles from a different service

It's quite easy to replace where the security service pulls its data, with your custom provider.
This is the core security configuration file
It merely describes the two important section:

  1. The TokenHandler service, responsible for generating and validating the security token.
  2. The security provider, 
    <bean id="securityProvider" class="org.intalio.tempo.security.simple.SimpleSecurityProvider" init-method="init">
 <property name="configFile">
   <value>${org.intalio.tempo.configDirectory}/security.xml</value>
 </property>
</bean>

The simple security provider has an LDAP equivalent called the LDAP security provider both implementing the Security Provider Interface

Security Provider has a number of key classes and interfaces associated to it:

  1. A list of realms.
  2. RBACProvider with all the related RBAC classes and services.
    1. RBACQuery, the query services for reviewing RBAC element sets, properties and relations.
    2. RBACAdmin, Administrative services for the creation and maintaince of RBAC element sets and relations.
    3. RBACRuntime, Runtime services for making access control decisions. This interface attempts to comply with the NIST RBAC Proposed voluntary consensus standard DRAFT.
  3. AuthenticationProvider giving access to the authentication interfaces
    1. AuthenticationQuery, Administrative review services for performing queries on users of the authentication system.
    2. AuthenticationRuntime, responsible for authenticating users.
    3. AuthenticationAdmin, for creating and maintening credentials.

By default, tempo uses the SimpleSecurityProvider which pulls its data form the SimpleDatabase object, which pulls its configuration from the security.xml configuration file, where the users and the roles are defined.

The easiest way to load users and roles form a different source is to extend the SimpleDatabase to load data from our custom resource, and then make the minimal changes required in SimpleSecurityProvider, notably the database configuration file checks.
One could of course, re-implements all the interfaces described above to get a complete integration with an external service storage for users and roles.

Integrate with other form-manager

UI-FW supports pluggable form manager out of the box. If your tasks have the proper formURL set at deployment time, it is possible to do configure mappings in the ui-fw config file. The following is set as the default:

<entry key="PIPATask">
    <map>
        <entry key=".*xform" value="/xFormsManager/init"/>
    </map>
</entry>

The default behavior of the pattern matcher would be to return the formURL as is, if there is one, or the value of the matched pattern.

So far, most of our forms have the xform extension, for examples: "/AbsenceRequest/AbsenceRequest.xform" so it will redirect to the /xFormsManager/init URL on the same server.

There is also a JUnit test case, that explains this in more detail.

Update orbeon used in xforms-manager

We use a jar-reduced modified orbeon. To update to a new version, I would suggest doing the following:

  • Download a new war version of orbeon from http://www.orbeon.com/
  • Replace/update all the jars we are using for orbeon. This is described in the dependencies.rb file.
  • Check the web.xml file for xforms-manager is still compatible. (And probably same for the geronimo-web.xml)
  • Check the page-flow.xml file is still compatible
  • Replace the following folders with the new ones: config, context, images
  • We had a slightly modified properties.xml to avoid some persistence features we don't use.
  • We had a services.xml in that same properties folder, so need to keep it
  • Also, restore the intalio CSS file
  • The folder formManager is left untouched

Internationalization of the UI-FW

Modifying the default language settings

To Modify the default language ( in this example, we are going to set the language as japanese ):

  • Open the file SERVER_PATH\var\config\tempo-ui-fw.xml.
  • Add the following bean in the "beans" tag :

    <bean id="localeResolver" class="org.springframework.web.servlet.i18n.FixedLocaleResolver">
    <property name="defaultLocale" value="ja" />
    </bean>

  • Restart your server.

If you want to set the language according to the language of the user ( the language settings of the browser) :

  • Open the file SERVER_PATH\var\config\tempo-ui-fw.xml.
  • Add the following bean in the "beans" tag :

    <bean id="localeResolver"
    class="org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver">
    </bean>

  • Restart your server.

Adding another language

The Intalio UI-FW currently supports an english and japanese versions. To add another language :

  1. Go to SERVER_PATH\repository\org\intalio\tempo\ui-fw\5.2.0.19\ui-fw-5.2.0.19.war\WEB-INF\classes ( the path will slightly change depending on your server version).
  2. copy and paste messages_en.properties and rename it. ( messages_fr.properties for french, messages_sp.properties for spanish...).
  3. Translate the values of the properties in the file.
  4. Modify the default language settings ( see above).
  5. restart your server.

Migrate data from Tempo 5.1

  1. Deploy the webapp called tempo-dao into your application server
  2. Copy the tempo-migrate.properties file into the usual intalio config directory of the server
  3. Edit the values accordingly to version 5.1 (using jdbc) and version 5.2 (using jpa)
  4. Check the jdbc driver can be accessed, or add it so that it is accessible from the webapp
  5. Access the following url: http://localhost:8080/tempo-dao/migrate and check no error is reported
  6. Click the "Start Migration" button
  7. Items and tasks that cannot be migrated will be reported in red.

Integrate Central Authentication Service(CAS), tempo and liferay with ui-fw-portlet

Let's use this system infrastructure for example:

Set up CAS server

  1. Deploy the project "cas-server-webapp" to your server or run the TRUNK/rsc/scripts/create_tomcat.rb to create a new tomcat server (You will find a webapp cas under the webapp root).
  2. Change the tokenService bean in WEBAPP_ROOT/cas/WEB-INF/deployerConfigContext.xml:

    <bean id="tokenService" class="org.intalio.tempo.security.ws.TokenClient">
    <constructor-arg value="http://tempo.com:8080/axis2/services/TokenService" />
    </bean>

  3. Enable the SSL connection of your CAS server using the keystore: TRUNK/rsc/liferay501/tempokeystore (if you setup the server via create_tomcat.rb, you don't need to do that). eg:

    <Connector port="8443" maxHttpHeaderSize="8192"
    maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
    enableLookups="false" disableUploadTimeout="true"
    acceptCount="100" scheme="https" secure="true"
    clientAuth="false" sslProtocol="TLS" keystoreFile="var/config/tempokeystore"/>

  4. Import the certification(TRUNK/rsc/liferay501/tempo.cert) into JRE

Set up tempo

  1. Run the script TRUNK/rsc/scripts/create_tomcat.rb to create a new tempo tomcat bundle.

Set up the liferay server with ui-fw-portlet

  1. Change the configuration file TRUNK/rsc/scripts/config.yml to enable the liferay server build up. (uncomment the 'server: liferay_v501')
  2. Run the script TRUNK/rsc/scripts/create_tomcat.rb to create a new liferay tomcat bundle.
  3. Change the file WEBAPP_ROOT/ROOT/WEB-INF/classes/portal-ext.properties

    cas.login.url=https://cas.com:8443/cas/login
    cas.logout.url=https://cas.com:8443/cas/logout
    cas.service.url=http://cas.com:8080/c/portal/login
    cas.validate.url=https://cas.com:8443/cas/proxyValidate
    cas.proxycallback.url=https://liferay.com:8443/c/portal/CasProxyServlet

  4. Change the file WEBAPP_ROOT/ui-fw-portlet/WEB-INF/web.xml: 
    <servlet>
  <servlet-name>JsonUpdate</servlet-name>
  <servlet-class>org.intalio.tempo.uiframework.service.JsonUpdate</servlet-class>
  <init-param>
    <param-name>TaskManagementServices</param-name>
    <param-value>http://tempo.com:8080/axis2/services/TaskManagementServices</param-value>
  </init-param>
</servlet>

Integrate ui-fw with CAS

  1. Setup CAS server properly (see previous FAQ).
  2. Change the WEBAPP_ROOT/ui-fw/WEB-INF/web.xml, adding this: 
    <context-param>
  <param-name>edu.yale.its.tp.cas.proxyUrl</param-name>
  <param-value>https://cas.com:8443/cas/proxy</param-value>
</context-param>
<filter>
  <filter-name>CAS Filter</filter-name>
  <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class>
  <init-param>
    <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name>
    <param-value>https://cas.com:8443/cas/login</param-value>
  </init-param>
  <init-param>
    <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name>
    <param-value>https://cas.com:8443/cas/proxyValidate</param-value>
  </init-param>
  <init-param>
    <param-name>edu.yale.its.tp.cas.client.filter.serviceUrl</param-name>
    <param-value>http://tempo.com:8080/ui-fw</param-value>
  </init-param>
  <init-param>
    <param-name>edu.yale.its.tp.cas.client.filter.proxyCallbackUrl</param-name>
    <param-value>https://tempo.com:8443/ui-fw/CasProxyServlet</param-value>
  </init-param>
</filter>
<filter-mapping>
  <filter-name>CAS Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

<filter>
  <filter-name>CASRBAC Filter</filter-name>
  <filter-class>org.intalio.tempo.uiframework.filter.CASRBACFilter</filter-class>
  <init-param>
    <param-name>edu.yale.its.tp.cas.client.filter.serviceUrl</param-name>
    <param-value>http://tempo.com:8080/ui-fw</param-value>
  </init-param>
  <init-param>
    <param-name>edu.yale.its.tp.cas.client.filter.logoutUrl</param-name>
    <param-value>https://cas.com:8443/cas/logout</param-value>
  </init-param>
</filter>
<filter-mapping>
  <filter-name>CASRBAC Filter</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>
    
<servlet>
  <servlet-name>ProxyTicketReceptor</servlet-name>
  <servlet-class>
    edu.yale.its.tp.cas.proxy.ProxyTicketReceptor
  </servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>ProxyTicketReceptor</servlet-name>
  <url-pattern>/CasProxyServlet</url-pattern>
</servlet-mapping>
  3. if the tempo and CAS server run on the same machine, could change both the 'cas.com' and 'tempo.com' to the same host. (eg: 'localhost')
Comments
Site powered by a free Open Source Project / Non-profit License (more) of Confluence - the Enterprise wiki.
Learn more or evaluate Confluence for your organisation.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 1.4.1 Build:#212 Jun 02, 2005) - Bug/feature request - Contact Administrators