Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
THRUST SERVICES & TOOLS
CLOUD EDITIONS
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Content Management (Extended ECM)
CSIDE and OScript
I have reinstalled Livelink and Builder..
DeloitteAdmin_(Delete)_2707331
Hi,I have reinstalled Builder and am ready to start from scratch.I've created an opace and have orphaned WFMAIN General call back scripts.I have modified the webbuilder.lxe so that my Ospace is always open when I enter uilder, but this does not work. My ospace is not open when I enter BuilderI have a workflow which has subworkflows, in the main workflow the user fills out a form and when that workflow is initiated the details in the form are passed to the relevant subworkflow.the name of the project manager is one of the fields in the form.What i want to use builder for in this case is to take the name of the project manager and attach that name into the Managemers area of the subworkflow. So the project manager will be able to view workflow status etc..At the moment this is being done manually, the workflow is initiated and then I manually add the name of the Project Manager to the Managers area of the subworkflow which has been kicked off...Can someone please provide me with guidance on how to do this?Thanks,Asha
Find more posts tagged with
Comments
David_Barker_(americ02user3_-_(deleted))
The module name wihtin the changeStateOspaces = {} parameter in the webbuilder.lxe file must be fully CAPITALIZED, otherwise it won't work.e.g. function WebBuilder( \ List changeStateOspaces = {'MYMODULE'}, \ ...Hope this helps,David Barker
David_Barker_(americ02user3_-_(deleted))
Note that I have not spent any time digging directly into this issue, but I did something relatively similar years ago, however without the forms.You will probably have to put the callback script on your subworkflows initiation or first step so that the Managers group already exists. Then you will have to get the managers user login id from the information provided on the form and then use some UAPI calls to add that user id to the subworkflows specific Manager group and set the perms.You will have to dig around in the WF code to figure that one out. I guess that there would either be a WAPI or WF module routine out there to get the WF Managers group information, but you will have to get that yourself. I would go into the page for that and trace that request through to see what it is doing and then mirror or borrow that code if applicable.David Barker
DeloitteAdmin_(Delete)_2707331
Hello,Could you tell me how to put a "trace" on?Thanks,Asha
David_Barker_(americ02user3_-_(deleted))
To "Trace" code in Livelink you must be utilizing Livelink Builder and then you simply need to turn on a "Breakpoint" somewhere in the Request/Reply code stream that you need to inspect. You do this from within the Builder by either double-clicking on the small GREEN circle in the upper right corner of any Livelink script feature when it is open or by opening the script and then typing "Ctr-B". When a breakpoint it set on the script the circle will then turn RED. You can do this even in a module that is currently Locked.Once you set the Breakpoint, you will have to Save the script by selecting File-> Save from the menu or typing "Ctrl-S" for it to take effect within the Livelink Servers memory space. Note, this will not affect the modules code permanently if it is Locked when you do this.However, you must always remember to remove any Breakpoints you have set on an Unlocked module before releasing it to production. As the Breakpoints will still be there and will cause the Livelink server to hang when the Request is issued.Once you have done that you can issue the request from your browser and then step through and inspect the code and data within Builder.You can also set Breakpoints on your HTML files if they are opened within Builder if you are troubleshooting your presentation logic. If you want to stop at a particular location within an HTML file you can add a ";scheduler.debugbreak()" call above the code and the Livelink debugger will break at that point.Most Request Handlers (RH) have an "Execute" script that contains the primary code for that particular Request Handler. This is usually the first place to start. You can determine what Request Handler is executing by inspecting the URL that is sent to Livelink. This is usually located in a Hidden form element that is named "func". The value of this element is usually something like "admin.setup" or "ll". In the case of "admin.setup", the admin portion refers to the collection of admin Request Handlers located within the WebAdmin module. You would then refer to the Execute script of the "setup" RH beneath the Admin RH object and set your breakpoint there to start.The "ll" request handler is a different kind of animal and operates quite differently from other RH's. Unfortunately I don't have the Builder in front of me currently to tell you which module it is located in. It's in something like WebDsp or one of the other core Web modules.I hope this helps to get you started.Dave