Copy This To That

Recently I saw a post in OT Forum that caught my eye https://forums.opentext.com/forums/discussion/comment/935976#Comment_935976 What prompted me to write this is because the OT experts also advised using some other mechanisms (XML WF Extensions and use of WR). Now, normally I like to code as well as any other user in Livelink a.k.a Content Server so why this post is because I remember when OT announced the Item Handler and Item Reference(yes they are different) several years ago I believe when Tammy Jakubowski(now GCI) was the WF Product Manager at OpenText.It was downright confusing but did it work in complicated situation boy it did. So I also asked the same questions why would you need WF Attributes and Form attributes in the workflow because they both do the same thing. But this user kept telling me that Business Workspaces apparently has a WF Step that creates BWS’s and it would only work with WF Attributes and they didn’t want their users to see the WF Interface

I replied with a simple OOB implementation where I used a simple throwaway hardcoded documents inside my WF Attachments map and using two Item Handlers Copied what a user entered in a Form Value to a Category to the throwaway Object and using a second step copied that Category Values onto a WF Attribute.

I later explained to the user in a series of simple screencaps how one would do this as that user needed hand-holding and I find the OT Online Documentation horrendously confusing 🙂 https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=77363139&objAction=browse

Advertisement

General Help Series 4- Workflow Maps/Instances

Livelink Workflows for the impatient

Livelink comes up with a extremely powerful Workflow Engine .At the minimum if you have only installed Livelink OOB you get a decent workflow features.This involves a “business user” to design a logical map that may involve “players” or “roles”.The only criterion is the process needs to be repeatable or it can be plotted in visio or such like.Note Livelink WF came before the wf consortium came up with open standards but it will have almost everything one sees in the standard.

Some key terms-

1. A WF Map.This is a dtree object identified by a dataid
2. WF Manager-By default the person who created the original map.Best practices dictate that you assign a proper livelink group as the ‘Master Manager‘.Not to be confused as the livelink team’s manager or a organizational manager.In theory this manager can re-assign steps and repaint the map.One of the few places where the sysadmin profile or the ‘admin’ user won’t cut it so due diligence thinking that at some point a higher up user may be asked to assist.Please do not run maps with <Initiator /> as the Master Manager.It is quite possible these users know only to click and when something breaks nobody can intervene.You can make them do only the “See Details” which is more than enough in many cases.
3. WF Instance- The process logic that is set in motion when a WF Map is set in motion a.k.a initiated .This is easily identifiable by a clickable link in the WF managers assignments and it will show in GREEN the step and useful info.
4. Steps-The series of steps that can be assigned to processes and users.This is what apparently the business user can be trained to paint..there are a myriad of steps that OT puts on the palette.
5. Role Based or Map Based-If you create a map OOB then livelink gives you a map where the forward steps can be done by business programming,like if WF attribute is green then my user is this group.If you change the map to “ROLE” based before initiation the Initiator will have to fill all the people in the workflow.People who use the Transmittals product of livelink can see this in action very clearly.
6. Attachments Volume- By default the attachments package is permissioned Full Control to “Public Access” very bad idea as when a casual user does search he will see unwanted or secretive results..Always put a good permission bit there.If you do not give participants Add Items up to Delete in that volume you will get crude messages from livelink . Note that the Truth Table implementation is observed by livelink on any kind of Object Creation so to get around problems in workflow OT assigns default full control to PA. Just observe what OT gives and change that to a good group and add all the people in the workflow to that group.
7. WF Attributes– Helper attributes modelled after category metadata .It allows the business user to route the map.
8. Forms-Optional Package see NEXT post.
9. Loop Back– Be extremely careful about this as you can create a infinite wf instance.
10. Item Reference– You can point to existing object subtypes in livelink like folders /documents etc so in conjunction with Item Handlers you can perform “auto magic”

It is quite possible that a good business user or a livelink user can be trained over a day to understand the process flow/swim lanes.I usually design my maps on a paper.I have a cheat sheet of sorts I maintain and many of the things in this article is based on that. Always check “Verify Map Definition” to understand any problems this may have.

The Item Handler is a predictive step modeled by some placeholder logic( Design Book 3) although which it appear useful it could look frustrating as very little process automation can be done just by it.The workarounds or “auto magic”  is usually a human at a prior step.If you use it with XML WF Extensions a lot of “auto magic” can be done with it.

The “XML WF EXtensions”  is a optional module that   uses the capability of livelink objects to have a XML representation(everybody probably has heard of XML Export/XML Import)

the XML WF Ext uses XML representations of livelink objects and manipulation of those objects by a SAX(or DOM not sure I know LL has both in it ) parser. Usually people get bitten by load balancers and file system permissions.

Like wise -XML Work Flow Interchange.Can send /call Web Services of other systems.

ESign – A specialized workflow that can do electronic signatures prevalent in 21 CFR11 operations.

Perfectly suited for livelink organizations who will not invest in Oscript coding /scared by OT sales/marketing in not writing Oscript understanding of this remarkable product.It was very expensive when I started livelink programming so it is a personal bias as well since I like to look at the map and many times I can get a 1-1 representation to the process.

OT Workflow Design 1 and Design 2 is a must read if you are doing anything with workflows.it also has decent interface methods for web services  as well

Event Scripts Debugging

 

I LOST ALL CONTENT WHICH WAS STORED IN COMMUNITIES.OPENTEXT.COM.IF YOU ARE A STARTER READING THIS AND WOULD LIKE TO SEE THE ORIGINAL CONTENT DEPENDING ON TIME I HAVE I CAN SEND YOU SNIPPETS.LEAVE A COMMENT TO SUCH EFFECT.

Getting Old.One of the most productive ways one uses Oscript is to create Event scripts in livelink workflow.

Workflows in livelink are perhaps the most easy ways to impress your clients and a lot of partners and ecosystems are built on top of that.Event scripting is taught or learned by one who has been introduced in livelink.But in a nut shell if you know how to paint a livelink workflow and thought of somethings like,how I wish OT gave me code to do this small thing which I am trying to do in a “kludge”. You may have noticed the “kludge” with how one uses XML WF Extensions ,to get to a document in the attachments area and do something with it.So a XML WFExt map looks very weird there will be a Export step,modify step for anything/ everything you want with it kind of very silly when you look at at the map.Fortunately when I was learning this XMLWfExt was high priced so we did not get to use it,hence we had to do it via event scripting. Once you get hooked into it man are you gonna love it. WR getting to attachments is also another inefficient way to do your stuff but the standard by line is oscript can break your investment.But when anybody wants anything done they would go to OT or Vendors who would you guessed it use Oscript to provide the magic.There is nothing more untruthful than this . Oscript when learned and done the correct way will survive years.To basically make a point I am going to attempt to see if a eventscript I wrote on 9.1 Sp3(circa 2003) can be made to work in 9.7.1(2013).I will even try to make it work in CS10 ,but then I will have to spin up a 2008 VM and so on.

Task At Hand:WF is initiated with a custom title made up of attributes, strings etc. The WF has four forms loaded into them and the template has a label and a field called TITLE  My job is to take the title and replace it on the form fields. Seems pretty  easy to do.

See My Map-

My template looks like this and I tried not to write code it does not work when initiating the workflow

Ok so as most of developers do I put a break in that script with just a echo statement to start doing my work so that I can see the variables etc. so as most new people will face I get this

and more importantly the debugger my task info is an ERROR.Without which I cannot proceed.I say this after 10 years because now I know how to do this.I did not at that time and so many of you will also go thru this.

So what do you do.After pondering for a while I resignedly said let me put it in another step and tell the user that it is a livelink limitation you will get an extra step in your workflow so click it to run the event script

so here’s my experience when I put the event script on the next step

Now we still have a error but that is actually joyous because we can now start debugging

But look at the TaskInfo variable now it has what we are looking for and trying to debug all the rest of the script

I managed to figure out the rest with echos etc and finished the script

Now HERES WHAT THE UNBELIEVABLE PART WAS .I JUST EXPERIMENTED PUTTING IT BACK TO HOW I WANTED , TO THE START PLACE AND IT WORKED

Since the project was a go I was very overjoyed.Later as I started reading articles by Jeff Lang,a great guy,who incidentally wrote livelink workflow he kind of explained the C++ firing and so on.We are friends and he has helped me and many other people when we got into a bind.I loved a post where he kind of admonished the developers who wrote XMLWFEXT….:(

See his post in 2007 I wish I had asked him in 2003 or learned it the proper way 🙂

In continuation here’s what you will definitely succeed start small,take baby steps and try some of these best practices

1. Event scripts can be debugged only if the work is committed in the database,means it has to initiate.What I mean is basically in WWORK the row is available.what looks as a “chicken & egg” situation may only be in development and really not in the real wf operation as I found by trial and error.Nowadays there is the IH step which you can put and assign it as a scheduled time.At the time I was doing this I did not have the liberty of such a step.
2. Do not chain event scripts into the start step,milestone that kind it makes debugging difficult.Start to a milestone these are auto done steps.Milestones later in the map should not have problems.
3. Do not have many things that a IH will do.Break it into manageable pieces.You will be grateful you did.

See where i posted this 

A really bad WF map made up of XMLWFEXT,WR,eSIGN etc the reason why the “kludge” is arrived is because of the designer not resorting to event script programming.Nor is the logic very sound.Stay away form those kinds.A business user should understand the wf map that is what the process is designed to support.Whenever I design a map I give the business user a standard swim lane diagram I find in the web.9 times out of 10 the map becomes much better that way.I also encourage my users to paint and change maps so it does not become a specialized livelink job.