Archive

Posts Tagged ‘DocApp’

kVisia: Product Overview

March 18, 2015 Comments off

Howdy Users and Buddies,

Today I want to share on kVisia, a product that provides the core functionality to automate, control and deliver an organization’s engineering and enterprise business processes to the desktop or Web. It holds the business rules, executes the XML configurations, builds the business forms, and implements the lifecycles that automate an organization’s business processes.

I think the only Prerequisites that you need to know is , Basic concept of client-server applications and Documentum Architecture.

Let me put it in Content Wise for better understanding with a bit of background of what’s there , what’s missing and how this can be achieved.

  1. Abstract

Today the current era is defined by the terms like data, information, knowledge, wisdom etc. and in this electronic world the difficulty to manage data in abundance has begotten many technologies and one of them is the Documentum.

Documentum is nothing other than a Content Management Tool but its vastness and its ability to cater to almost all sorts of data types available are so rich in itself that these days it is widely used. If we undo the Documentum technically then it gives an edge over the Relational Database Management System by not storing only the Meta data but also storing the content in its native format.

kVisia blends with Documentum to bolster the level and depth of automation which can be achieved by the Documentum alone and this is what this document discusses in detail.

  1. Introduction

kVisia comes of McLaren Software Limited and users need to have a license before using it. McLaren is ISO 9001 certified and it has been accredited Independent Software Vendor for Documentum and FileNet. It has got 360+ customers worldwide and it operates from UK, USA and Switzerland.

In fact kVisia is an Enterprise Engineer product that encapsulates best practices and domain expertise. This is a user configurable application consisting of XML files managed by repository and standardized on a single ECM platform. It is also believed to be powered by Documentum.

For better understanding of the kVisia we can go through the following questions and answers that will help one to identify the need.

How does it help me?

Very quickly configure the user interface and deliver it to the Desktop and Web users.

Is it easy to change?

Very easy, configuration files are stored in the Docbase in XML format.

Configurable interface using objects and tables.

Do the configuration files allow me to control inputs?

Very complex business rules can be enforced via the XML files.

Validations at creation, promotion and check in.

  1. kVisia suite

kVisia suite consists of following three components:

  1. McLaren Studio
  2. McLaren_Core DocApp
  3. McLaren_Foundation DocApp

3.1 McLaren Studio

McLaren Studio provides a user-friendly desktop application that allows users to create and edit XML configuration files that will conform to the rules of the Document Type Definition (DTD).

An XML (eXtensible Markup Language) configuration file is a structured file consisting of many elements. Elements are ordered into a tree structure or hierarchy. Elements may have parent or child elements, and may also contain attributes. An element without a parent element is the highest in a tree structure and is called a root element. Not all of the elements will have child elements.

The structure of a valid XML file is defined in a DTD (Document Type Definition) file. The DTD contains the rules that apply to each XML configuration file; these include the definitions of parent and child elements, element attributes, and how each element can be used

The appearance and behaviour of user dialogs can be modified without the need to change programme code simply by changing settings in the appropriate XML configuration file. A definition of the appearance and behaviour of a dialog is referred to as a “configuration”. A common need, however, is to display different configurations under different circumstances. For example, members of different groups may need to fill in different properties on documents, and the document’s properties may change as it moves from state to state in a lifecycle. The definition of such a scenario is referred to as a “mapping”. When you do not want to differentiate functionality between different groups, lifecycles and states, there is a value called {default} that will apply to all circumstances.

The Actions for which dialogs can be defined using an XML configuration file are:

 New

When the user issues the New command, a customized dialog can be displayed. Commonly deployed features include automatic document numbering, interactive project allocation and any additional attributes (optional or mandatory), which may be required to be stored for the document.

 Properties

A customized Properties dialog can be displayed. Fields can be made editable or read-only as required.

 Import

When the user performs an import, a customized dialog can be displayed which may typically employ features similar to those used in the New dialog.

 Copy

When the user performs a copy and paste action, a customized dialog can be displayed which may typically employ features similar to those used in the New dialog.

 QuickFind

For each document type, a search dialog referred to as QuickFind can be defined and viewed by the user in the Docbase through the McLaren menu. The attributes that can be searched on are configurable and search options such as Between, Greater Than, Containing, etc., can be specified.

 3.2 McLaren_Core DocApp

Having installed kVisia you get two sets of Docapps in the Docbase, one is the McLaren_core and the other one is McLaren_foundation. The McLaren_core Docapp is available to the user of a Documentum repository. It is always suggested that one should have the overview of the additional functionality as a result of the deployment of the kVisia before configuring the product to suit the business need.

As the name suggests McLaren_core Docapp provides the basic functionality like New, Import, Properties, Copy, QuickSearch etc to be configured. As discussed above, we use the XML configuration tool McLaren Studio to configure it.

For each Object Type used in the repository, an XML Configuration File can be created and configured to define the appearance and behavior of the various dialogs for documents of that Object Type. The definition of the appearance and behavior of a dialog is referred to as a configuration, and different configurations can be displayed in different circumstances.

3.3 McLaren_Foundation DocApp

The McLaren_foundation installation enables you to deploy a pre-configured implementation of the Core technology which transforms it into a user application specifically adapted to the engineering environment, providing a ready-for-use engineering repository. It deals with the following configurations:

User Roles that is associated with Menu Systems and User Dialogs that are adapted to those roles.

Object Types for documents and folders.

XML Configuration Files that define the content, appearance and behavior of the New, Copy, Properties, Import and QuickFind dialogs for the supplied Object Types in accordance with the current user’s User Role and the document’s lifecycle and state, including pre-configured, automatically generated document numbering.

Check in dialogs which are specifically adapted for each supplied type of engineering document.

Automated document revision numbering that reflects common design practice. Revision numbers start at 0 and the first issued version is 1, the second 2, the third 3, etc. When a document is checked in for the first time, a numeric value is assigned and incremented each time it is checked in.

  1. Traditional – VB (Desktop) Vs kVisia(Desktop & Web)

Following Comparison lets you know how much flexibility kVisia provides and how much time and effort it saves.

Traditional – VB (Desktop) kVisia (Desktop and Web)
Ø  Obtain VB source code.

Ø  Open VBP.

Ø  Edit GUI.

Ø  Add code to populate list.

Ø  Add validation rules.

Ø  Save source code.

Ø  Compile DLL.

Ø  Create CAB file.

Ø  Open DocApp in Composer

Ø  Edit the component ACX and

replace CAB file.

Ø  Check DocApp back in.

Ø  Not available until next user login.

Ø  Check out XML.

Ø  Edit XML kVisia Studio.

Ø  Add XML tag.

Ø  Specify properties.

Ø  Save and Check back in.

Ø  Change available immediately (no logout required).

  1. Benefits
  • Easy to manage development process as applications are configured via XML using Studio
  • Fast route from innovation to user acceptance
  • Shorter time from design through to development
  • Shorter time to deploy to the business users
  • Reduces development costs
  • Future upgrades are minimised
  • Simple deployment and at a local level of control
  • Speeds up implementation process through rapid configuration

Hope you like the post, Feel free to post your comments and I will reply back to any queries that you have.

Adios , Have a great day ahead…

Creation of Workflows in Documentum using Workflow Manager

December 3, 2010 Comments off

Workflow is the automation of a business procedure, during which it specifies how content (document, information or tasks) is routed for review/approval from one participant to other, before it is released to the system. Users are notified by e-mail when they have some content to review.

Role of Workflows in business:

Workflows help to streamline the business process.Reduced time, fewer mistakes and improved quality of work. Information about the task readily available at any point of time.

Uses:

  1. Improved change management.
  2. Improved services and management.
  3. Inter-Organization communications.
  4. Reduces operating costs.
  5. Improved productivity by automating routine and repetitive tasks.

Every workflow has a number of logical steps. This is called as an Activity. An Activity could involve manual interaction or can use machine resources. Activity involving manual interaction is called as a Manual activity. Manual activity has a performer. Activity which doesn’t require manual intervention is called as an Auto activity. It’s performed using machine resources.

Flows are the connectors. They connect the activities. They also specify the sequence of activities. Workflows may be parallel or serial. In serial workflow, tasks follow one after another in a sequence. In parallel workflow, two or more activities can happen concurrently.

Steps to create a workflow:

Once the business process is known, before creating the workflow, answer these questions for a better workflow design.

(Plan the workflow using the following points)

1.    Who initiates the workflow?

§  The person going to initiate or start the workflow should have ‘relate permission’ on the workflow template to start the workflow.

2.    Decide which activities are going to be manual activities and which are auto activities

§  Whether activities will be performed in serial or parallel

3.    Who is going to perform the manual activities?

§  Whether its going to be a specific user, a group, or some number of performers from a group will be included in the decision making process,

§  Whether the performers will be chosen at runtime or will the performer name be hard coded in the workflow template.

4.    When does an activity start?

§  When an activity has more than one incoming flow, you can specify how many activities should complete before this activity begins. This is the trigger for an activity.

5.    What are the activities that happen next?

§  How is the next activity chosen?  Whether the performer chooses the next activity, or all the activities connected to this one is chosen, or the next activity can be chosen based on some conditions.

6.    What documents are passed along the activities?

Some documents will be passes along these activities, on which some actions are performed. Packages can be added, through flow inspector connecting the two activities.

Given below is a sample workflow.

This workflow depicts a scenario of bank, wherein the concerned department receives application for loans, the loan papers are sent for review to the manager who then decides whether to grant the loan.

Now, let’s answer these questions for the above scenario.

1. Who initiates the workflow? – The clerk who receives the loan application from the customers. He/She should be given relate permission on the workflow. When a new loan application is received and it needs an approval from the manager, the clerk applies a workflow on the loan application.

2.    Decide which are going to be manual activities and auto activities:

Manual activities include a task where in the manager approves or rejects the loan. Auto Activity will include the business logic when the loan is rejected or approved.
We can call the Review activity by the manager as a manual activity.

3.    Who is going to perform the manual activity? – The performer has to be decided. Manager would be the performer. Instead of hard coding the manager id in the performer name, the performer could be chosen at runtime by the initiator. (This makes the workflow template more reusable.)

4.    What will trigger an activity in the workflow? – The next activity depends in the action taken by the performer. If approved, ‘Approve Loan’ activity will be triggered, else if rejected, ‘Reject Loan’ activity would be triggered.

5.    What documents are passed along the activities? – The documents passed along the activities in this case could be the loan papers, and other documents required in the process of Loan sanction.

This is the workflow template for the above given scenario.

‘Review’ is a manual activity.  (The option, the activity’s work is performed: By one more manual performers is chosen)

To select the performer, click on the select performer tab.

While selecting performers, Select option ‘some users from a group’, if there are many managers who review the document. Or select ‘single user from a group’, if the task will be sent to only one manager for review.

The Option ‘Multiple sequential performers’ will send tasks to the reviewers in serial fashion.

To choose the reviewer at runtime, select the option, ‘Have performer(s) of activity <Choose the activity here> determine performer(s) of this activity’.

Transition tab is to specify which activities should be started next. The option ‘Let the activity’s performer choose’

If there are three reviewers, and if the task is sent in parallel, and two of the three reviewers approve, and one reviewer rejects the loan, then we can chose either reject activity as the next activity, or approve activity as the next activity, as per the requirement.

Reject Loan is an auto activity. When a loan is rejected, the business logic is written in a java class, and that java class will be specified in the section, Execute this method automatically.

To get a method in this dropdown, create a method in DocApp, select option use as workflow method. To set up a java method as a workflow method, click here

Auto activity is executed using some permission. There are 4 options to choose from. The auto activity will execute depending on these permissions.

Review complete activity is another manual activity, which notifies the workflow supervisor that the workflow is complete. Again this activity solely depends on the requirement.

Flow inspector is used to pass the necessary documents between two activities.

To add a document, click on ‘Add New package’ and enter respective name and package type to be routed through the activities.

To set up a new JAVA method to run as an automatic Workflow method:

Create a method using DocApp with the following attributes.

Name: Method Name

Command: <classpath> or <classname>

Place the resultant class file where the Java run time on the Content Server machine can find it.

E.g.: 1) package.com.cs.server.classname- the class file should be present in the package.

2) Classname- the class file should be present in \dba\java_methods.

 

Run synchronously: True

(Time out in seconds)

Minimum: 60

Default: 100

Maximum: 300

Run as Server: True.

Trace launch: True

Use Method Server: True

Launch directly: False.

Use as workflow method: True.

You must check the option ‘Use as workflow method’ to make this method available for use in workflow templates. When “Use as workflow method” is set to “True”, the attribute “a_special_app” will be set to workflow. In order to have a custom method available for use in an Activity in Workflow Manager, the attribute, ‘a_special_app’ must be set to workflow.

Setting “Trace launch” to “True” in the method attributes will allow you to see this debug information printed to the server log, log4j.log. This can be used for debugging purposes.

 

Now, the created .class file should be placed in any of these two locations. As specified in command attribute of DocApp method.

1.       package.com.cs.server.classname – the class files should be present in the given hierarchy.

2.       The class file should be present in <DM_HOME>\dba\java_methods

The java class file should contain “acquire()” and “complete()” methods for it to run as an Automatic workflow method.

acquire(): Acquires a work item for the current user.

Work items are tasks in the workflow. After a work item appears in a performer’s inbox, the performer must acquire the work item before beginning work on the item. The user issuing this method must be the work item’s performer, the workflow supervisor, or a user with Sysadmin or Superuser privileges.

Executing this methods changes information in the queue item associated with the work item

complete(): Marks a work item as finished.

The user issuing this method must be the work item’s performer, the workflow supervisor, or a user with Sysadmin or Superuser privileges. The work item must be in the acquired state. If the method is successful, it sets the work item’s state to finished. Executing this method changes information in the queue item associated with the work item

// custom code needs to be added.

Steps to set up a custom workflow method in docbasic:

Create a method in DocApp

Set the type to dmbasic.

In the command tab, give the path as: .\dmbasic

–f\Documentum\product\5.2\install\admin\ebs file> –e

E.g.: -fD:\Documentum\product\5.2\install\admin\Loan_Approval.ebs -eLoanApprove

Place the file in the following location: <DM_HOME>\Documentum\product\5.2\install\admin

ACL on Workflow templates:

The workflow templates created needs relate permission to be used.

This can be done through DA  by running this (DQL)query

 

Update dm_process object  Set acl_name = ‘ACL Name’ Where object_name=‘Workflow Name’;

This will allow the user to apply the workflow on a particular document.

%d bloggers like this: