Help with integration

Jordan_Fuller
Jordan_Fuller
in Extended ECM Integration #1

Good morning! I hope everyone is safe and well.

My question is "where to start and what to do" and I am hoping that someone can help. We have a BPMS application (Appian) and we are wanting to embed Content Server within the application so that our users can store files directly within Appian.

Where do we begin and what are our options?

I've looked over several OT webinar's on xECM and it refers to a widget. It is pretty simple to embed an xECM or CS Node into a page? Is it all just API calls? I'm confused as to how it works with 3rd party systems. is it an iframe embed? do the API calls return the CS window?


Any help for this newbie would be helpful.

Comments

  • Appu Nair
    Appu Nair Member
    edited February 12, 2021 #2

    Nowadays you cannot find a Content Server without having XECM modules. CS used to be a pure DMS with Search, WF, and Library aspects. XECM is a bolt-on framework on top of CS so what I say is assuming you have XECM but again what you hear as SmartUI is what the XECM widget is built so if you know to manipulate then any OT smartui widget will work. If you don't like what you see in an OT smartui -- these are SPA's. I used this XECM example only because I currently am involved in a project that uses it. In my project, I had a need to show a FolderBrowser widget which is detailed in the SAP documentation this is one of its earlier cases when code was not very maturehttps://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=68719613&objAction=viewincontainer&ShowReplyEntry=68757223#forum_topic_68757223

    I am not a modern-day JS programmer so you will see the gurus like Ferda talk about using completely JS frameworks helping it build and so on.

    This is a good guide for you to start some exploring

    https://knowledge.opentext.com/knowledge/piroot/eep/v160200-00/eep-cgi/docovw.xml

    in there you will see something like this

    image.png


    The first link shows you a JSP to play with it just create an HTML file and throw everything in that code change the place holders appropriately to your content server etc

    The connection code invokes content server restapi with a hardcoded userid /password. Unfortunately in that example, OT developers think that the consumer knows everything but in this case, that example lacks an element in the HTML body I don't think it is there where you see <%= workspaceNodeId %> if you have a working livelink URL ( something that ends in cs.exe,llisapi.dll) then just go to any Folder in your livelink and put it like start: { id: 2000 }

    If it works then you know that this UI Widget SPA will work so long as it knows how to authenticate....

    Now start thinking about integration(in my case I cannot hard code a userid, password so I wrote a server implementation to handle that)

    This is the code the OT Example was missing

    <HTML>


    <body>

    <script>

    all the code form OT as in document including that

    workspacesWidget.show({placeholder: '#widgetWMainWindow'});


    <script>


    <div id="widgetWMainWindow" /> //OT expects programmers to know that a div is doing the painting....

    </body>

    </HTML>

  • Jordan_Fuller
    Jordan_Fuller
    #3

    Thanks this was really helpful.

    How did you build your own integration for username/password? Are you referring that you passed the username/credentials into it or did you get an OTCS Ticket?

  • Appu Nair
    Appu Nair Member
    #4

    The leading app that I work with it has a java framework so it allows me to write JSP pages and solid POJO so my approach was to request the user who would call the CS Widget and once I got that I pass that as the session ticket constructor...

    The OT SmartUI Page is coded to look for an authentication header they do not care if it is a ticket or a username/password or LLCookie once you play with POSTman and the rest of API many of the things will make more sense.


    #AOTDEV45D

  • Ferdinand Prantl
    Ferdinand Prantl E Community Moderator
    #5

    CS core offers you either iframes with Classic UI request handlers, (ActiveViews, WebReports, custom) or Smart UI widgets.

    The former is the traditional way using cookies for authentication with SSO provided in the same way as it works foe the built-in CS web application. (If you do not have SSO and need small iframes, you will need to enforce the authentication by a special page to prevent rendering the login form in a something like 200px rectangle.)

    The latter is the new way for embedding parts of Smart UI on other pages than the CS Smart UI application (/app). You can place the widgets to iframes too, but if your portal allows JavaScript extensions, showing a widget by JavaScript in the same DOM offers better user experience.

    The widgets have to be authenticated by the integrator. They inlcude no built-in automatic authentication. The JavaScript code with the widget initialisation is usually generated on the server (ASP.NET, JSP or other template engine), including the authentication token (OTCSTicket). The server-side part of the integration can use CS and/or OTDS REST API to obtain the token, preferably leveraging some SSO implementation.

Categories

image
OpenText CE Products
Extended ECM
Docs & APIs