How can I develop my own Modules for Content Server?

Alexandru Ghita

Hello,

My team is trying to create our own module for Content Server, we need something more customized when it comes to the signature workflow, especially for working with digital certificates and for the user interface.

What options do we have for this? Is there an SDK for this or some kind of guide? (I was not able to find something that matches our needs yet).

Note : We can't Core Signature or AppWorks. Do we have a third party option for developing this?

Thanks!

Appu Nair

@Alexandru Ghita

The OTCS code base that is open for Partner/Vendor/Organizations' development is OSCRIPT a proprietary language that you learn under the auspices of OT Learning where they take you through typically done things in Livelink. Since it is not a cheap course many will resort to the standard "Hello World(They call it Contacts or Recipients modeled after the old addressbook module)" SDK OT has been published so chances of doing a good module remain to be seen. There are certain fundamental class objects and drop-ins that we as developers cannot see but for the most part, one could understand about 90-95% of Oscript code. The search is a big jar file that gets called from Oscript I have no idea how they develop search. On top of it, there will be teething difficulties and a steep learning curve/frustrating moments with CSIDE and so on. The APIs, while they have external language supports SOAP or REST or language support NET/Java still the real code on the server, is in Oscript. Oscript has internal APIs as well that will get you productive in lesser time.

The SmartUI SDK is a quantum shift in the older technology like weblingo which is akin to jsp/asp. However, what I think it suits is medium to high knowing modern javascript frameworks(Marionette, Angular, React), etc. If OT does not have a REST API that you could call then one needs to write Oscript to create it. Otherwise, the current Oscript requirement is to follow religiously the SDK which results in "minified" JS resources that go into an Oscript module(mostly so that the server can see it). You need almost nil knowledge in Oscript to create the SUI SDK if all the calls you need are provided by OT.

The author myself as well as several OT Developers used to support Oscript like a religion however of late OT has been not supporting the community that well here is a page that will list a lot of people https://greggriffiths.org/livelink/ I put this here because many of the people in that list except myself are capable of working as "third party" since you asked for that possibility.@John Simon my mentor is a go-to resource on anything livelink . He probably watches this but his company is called knowledgeworks canada.

@Greg Griffiths, you might add Mathew Barben to your list because he gives a lot of good ideas on SUI. Talking technically many things you can do by using the Oscript java Bridge

https://appukili.wordpress.com/2013/04/15/to-err-is-javato-forgive-oscript/

https://pos2007.de/calling-java-code-from-oscript-1

It is easy enough to develop most of what you need integrated developing in java and once you are satisfied with that you can from Oscript 'call' it. There are many "caveats" on that as described very nicely in Reiner's Blog @Reiner Merz , my article is way too old. I recently exercised this in a product I wanted to do and it was not that bad. It wasn't probably possible with my knowledge to d this totally in Oscript

This is the OTDN link

I would look at the SDK self-guide and install CSIDE and play with a small Livelink server if you are serious.

The above link is for paying customers :) whilst this forum is simple web registration. You will not find a lot of Oscript blogs or examples if you are not a paying Livelink customer.

Sorry for the long post I don't know if I could answer things in very short spurts...

Greg Griffiths

As @Appu Nair mentioned there is the OT Developer Training (https://www.opentext.com/TrainingRegistry/course/details/2980) although depending on what exactly you need to do, you may be able to do it using WebReports (https://www.opentext.com/TrainingRegistry/course/details/2925) or SmartUI (https://www.opentext.com/TrainingRegistry/course/details/2928) etc.

If you can provide some more details of what you are trying to do, we can advise on the best approach to take to solve it.

You may be better hiring a freelancer or a firm to develop the component for you if you don't want to upskill you team.

Alexandru Ghita

Thank you so much! @Greg Griffiths and @Appu Nair !

From what I understand it seems very difficult to upskill our team and develop our own module, that is why we were thinking about some workarounds.

The problem pretty much is something like : We need a signature workflow that can work with digital certificates and HSM and that lets the user select in a UI the place for their signature, we can't use Core Signature for this.. So we thought about a workflow where the user attaches the document and is sent to another webpage that captures the doc, lets the user sign it and sends it back to the workflow.

Does this sound do-able to you? Any tips?

Appu Nair

@Alexandru Ghita

The Workflow is a great tool for OT to do some choreographed steps but the standard palette is very basic. If you use OT's WF solution called eSIGN it has some bells and whistles to call some external services.OT has created many WF tools and the latest one is WR WFEXTensions which is not the same as standard WR. One of the ways I would make it easy on this is I would choreograph the WF steps and front end it with standard Forms which you can dress up with aesthetic styling using your power whether SmartUI support or classic. Once you are in the Form View you have at your disposal Livelink server resources you can call Ajaxy stuff as well as API's to your Signing software. For Ajaxy integrations, only classic can be used.

There is a higher learning curve for two other WF offerings from OT one is called XML WF Extensions and one is called XML WFIC they are used to exchange Livelink Info to other systems and back. If you don't have deep internal contacts or infinite patience most users will have teething troubles with those. Further, they are never synchronous things, more yesteryear where you give a file to some program, wait and retrieve the finished one so it will not be as slick as the main signing software one has come to expect.

I know my friend @David_Henshaw sometimes peruse these forums and I know he has tremendous experience in signing aspects. Perhaps he would provide some input.

WR WF Extensions along with standard WR could probably be used in lieu of Oscript programming.

Alexandru Ghita

Thank you so much @Appu Nair for your response, we will definitely look into Web Reports and the extension (I tried installing the extension module, but I got an error message with no more details, and the OTCS instance broke, need to reinstall it), to give more information we need a way to implement an external web page/API (possibly developed with Angular), where the user that needs to sign the document, can see the document itself and can choose freely where he signs(much like in Adobe Acrobat), that external page/API needs to capture that document, do the technical digital signing, and send it back to the workflow for the next step.

I want to know if the WR Extension can help us implement this while keeping the User Experience still quite simple and intuitive.

---

Hello @David_Henshaw , I would really appreciate a chat with you via email or another platform, maybe even a teams meeting, we could really use the help of an expert regarding signing aspects for OTCS.

Thank you !

Appu Nair

@Alexandru Ghita Wanted to see if the following will help with your broken instance.

The WR WF Extensions module should not be confused with XMLWFEXT or XMLWFIC

I see it is only available for 16.2 perhaps a newer version has it baked already or the WR License you buy would make it eligible. in fact, in an instance of 21.2 where I checked, I saw it already available.

https://knowledge.opentext.com/knowledge/llisapi.dll/open/33375228

Don't know if you had a backup before you installed perhaps many module install problems can be corrected without re-installing.

FYI the handle you are using is an old handle for him this is the new one

@Henshaw_David

https://forums.opentext.com/forums/support/profile/discussions/Henshaw_David

Alexandru Ghita

@Appu Nair Thanks, I managed to reinstall OTCS and it works now again, I did install WR Extension 16.2, I can't find anywhere another version to test with.

--

@Henshaw_David I would really appreciate a chat with you via email or another platform, maybe even a teams meeting, we could really use the help of an expert regarding signing aspects for OTCS.

Thank you guys!

David Henshaw

@Appu Nair - thanks for the mention, appreciated.

@Alexandru Ghita - Thanks for the reach out. By way of introduction, I am VP Products for Fastman. We are an OpenText partner (two partner types, services and technology) and amongst other things we produce an extension solution for Content Suite handling digital signing via DocuSign.

The solution supports both cloud based signing (DocuSign Agreement Cloud) and also on-premise signing using the DocuSign Signature Appliance (highly useful in tightly regulated environments where content cannot leave the organisational firewall).

Signing is support both via Classic and Smart View in Content Suite, and also via workflow (both interfaces).

More detail can be found on the Fastman website (www.fastman.com), including a contact form should you wish to reach out for further information and/or arrange discussion.