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-
A WF Map.This is a dtree object identified by a dataid
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.
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 GREENthe step and useful info.
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.
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.
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.
WF Attributes– Helper attributes modelled after category metadata .It allows the business user to route the map.
Forms-Optional Package see NEXT post.
Loop Back– Be extremely careful about this as you can create a infinite wf instance.
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.
LAPI and its client installer has become very hard to find. Moreover clients written in LAPI in say Java/.NET will only work if your Livelink a.k.a Content Server is of version less than CS16.Readers who are new to LL programming is encouraged to read this to the approach and not to the exact lines of the code.What I mean is when you used to program in LAPI you were basically passing parameters to discrete calls by modelling it based on the webgui of livelink .SOAP based webservices called CWS is also the same,so if you do not try to do the task in the webgui and try to understand the business rules you will almost have no success in CWS too. OT is notorious for not putting fully functioning use cases and a walk through,so whenever possible I write code assuming the user has not worked in Livelink for X number of years and try to educate you all. Livelink,Content Server,Enterprise Server all of this has been Livelink’s marketing brand name changes over the years.CS i sused in many of the integrations like AGA, XECM, RMLINK and you know you are programming against livelink if you see a link that looks like this http(s)://somefriendlyURL/livelink.exe|cs.exe|llisapi.dll|cs.dll|livelink.In many places SAP/ SP /Exchange will be configured to talk to Archive Server and then they will use Livelink to read into archive server and turn that into LL objects for better presentment/RM and other aspects. The AGA product is moving away from LAPI(not sure totally or not) to REST API in LL.
Again my guess is the programmer does not no enough about how livelink handles workflow data structures so hopefully my article does some help. A frustrated developer in this case because there ain’t official samples from OpenText will start to trash the product which I hate to be happening. OT is busy with Core and Appworks(nothing was said about this at conference so is it already dead?) it seems and to this day I cannot understand why OT responses to WebReports is such a high pleasurable experience whereas everything else is basically a lukewarm thing.
I needed to brush my new java skills so I downloaded java samples from KB and started looking at it. It looks to me there is a lot of setup one does with java in C# alsl one does is type a little bit of code….Anyway the poster was using System.out so I am guessing he was a java programmer.There might be several better ways to do it but what I did was convert my old C# code to do that
Workflows are Churned by a map created in livelink See Pic of the new 10.5 Map
When you Click Initiate a WF Record is inserted with a pair of dataids called WorkID, SubWorkID in most simple workflows they are the same when you or livelink creates subworkflows they differ.
By programming all you are doing is making sure you can get to the running instance and look at its internals
It never seldom one changes the logic of map with CWS or LAPI programming.
The livelink workflow carries several packages of the workflow,when you say you want Attachments you get a Container much like a folder to put documents,if you say Attributes you get that,if you put a Form template you get that and so on and so forth
The above map is reproduced faithfully in a table that is how livelink knows the evaluate conditions etc, if you change the real master map then only instances churned form that will be affected not earlier ones
Attributes and Forms are basically going to borrow/rely heavily on categories and attributes code
Anybody who has worked with traditional HTML forms/PDF Forms know how cumbersome its making is in livelink. That is because the form template is rigorously tied to livelink code .The WF /Form developer sits in front of livelink many time not knowing it is submitting to a livelink RH(all those hiddens you should not touch).The submitted POST data is parsed by livelink code to do all the crazy things you want or your manager wants you to deliver to a customer requirement. There is a frantic look for help in this and after perusing the KB for a lot of stuff one finds something and basically in about a week’s time one is able to write something that works. Then comes the big questions like it all looks very kind of unaesthetic. So lo and behold some kind of WYSIWYG editor is employed and lots of colors aesthetics applies and then TONS of java script errors on views….The smart cookies will figure out the JS errors and proceed but all done it is a good effort to do anything with it. In fact most of the Best Practices you will find about editing form templates/forms/views were even taken verbatim from old discussions are findings I posted when I was developing forms etc for my wf /form project years and years ago and they still hold good. The world has gone to WYSIWYG and nobody hires programmers for doing html/JS etc .While OT has their own version of WYSIWYG editor kind of forms (eForms) or something like that it is also not very that easy or intuitive .At least for me when I tried it several years ago so take that with a pinch of salt.
Now compare that to Patrick Vitali’s Product. It is an amazing, jaw dropping revelation to how one uses livelink and its forms capability .I do not work for him nor do I get remunerated for this but a good friend. I also make it a point to reward good things without expecting anything in return. Mind Blowing that is the real word that comes.