Smart UI SDK 21.2 "broken" ??

IS there something amiss with the 21.2 Smart View SDK that anyone has come across?

I've downloaded from Content Server Smart View SDK 21.2 (opentext.com) the SDK and the csui-generator.

I am using Node 14.16.1 (under nvm), npm version 6.14.12.

I have installed the csui-generator, noting that this produces the "primordials undefined" error - see Smart UI install fails while trying to contact OpenText address — OpenText - Forums - which I have fixed using Appu Nair's comments.

The process I then follow is per below.

  1. Create a new folder for the new solution.
  2. Open command prompt to this folder and run yo csui-extension. Accept all defaults.
  3. Then run yo csui-extension:widget, again using defaults. When asked, overwrite the existing files.
  4. Run grunt. This produces an error when running the subgrunt:compile task -

>> TypeError: csuiComponent.getAllRequireJsPlugins is not a function

Warning: Task "default" not found. Use --force to continue.


Trying with grunt --force proceeds further, but doesn't produce final outputs (i.e. no out-release folder is generated).

Compare this with following:

  1. Create a new folder for the solution.
  2. Open command prompt to this folder and run yo csui-extension. Accept all defaults.
  3. In the /lib/src/ folder, there is a greet folder. Copy the contents of this folder and place in /src (under folder created in step 1).
  4. Run grunt. Error reported that module printf cannot be located/found - run npm install --save-dev printf.
  5. Run grunt. Error svgson not found - run npm install --save-dev svgson.
  6. Run grunt. Warning - Task "concurrent:finish" not found. Run npm install --save-dev grunt-concurrent.
  7. Run grunt. Build proceeds, though fails tests. HOWEVER, we now have out-release of built code.


This leads me to conclude that the csui-generator for 21.2 available from the OT KC is correct, producing build files that pre-date changes in the 21.2 SDK (i.e. move to "nuc"leus).

@Ferdinand Prantl - if you're watching - are you able to comment here? My goals are to A) ensure the SDK works and we can produce new solutions and B) convert existing solutions such that they can be built against the new SDK.

Regards,

David Henshaw

Tagged:

Comments

  • Ferdinand Prantl
    Ferdinand Prantl E Community Moderator

    You encountered three problems:

    1. Outdated generator dependency. It is not new and you dealt with it well.
    2. Missing npm dependencies in package.json. It is easy to deal with as you did.
    3. The error about the missing function "csuiComponent.getAllRequireJsPlugins" during the build.

    The last problem is fatal. I checked the generator and I did not find the proper migration to CSUI 21.2 there.

    Could you file a bug about this at OT CS, please? Your forum post is an exemplary bug report, which will be easy for the developer to start with. Thank you!

    Workaround

    You can decide to:

    1. Continue using the generator and SDK 21.1 for your new projects.
    2. Migrate the newly generated project to CSUI 21.2 before you build it.

    The generator in the SDK 21.2 is supposed to generate a new project compatible with sources of CSUI 21.2. Until that is fixed, you cannot start using the generated project right away. But the version of the generator or SDK that you need does not have to be absolutely the recent one. You need a minimum version that exposes all extension points that you need and works in the contemporary Node.js environment. I doubt that 21.2 introduces a new extension point that you need to depend on. If you do not use an ancient version like 16.0.3, you should be fine.

    Existing development projects have to be migrated to CSUI 21.2, because as you wrote the component csui was split to two - Nucleus (nuc) and the rest CSUI (csui). The module-loading compatibility map ensures that previously developed solution continue working. And of course, new solutions developed with the SDK 21.1 or later too. A Smart UI development project has to be migrated first when you want to build is using the SDK 21.2 or newer. Which means that you can postpone it for quite a long time and let the migration be driven by other reasons, like a new CSUI extensibility needed, or upgrade to a newer Node.js.

    I attached the migration instructions, if they are not included in the SDK. If you rename it to .md, you can read it in a Markdown viewer.


  • Thanks Ferda. I'll raise a bug with support....I'll mention this post in the support request and you're advice, as being fair, I don't think the support front line will "get this".

    I've also got a support request raised about user session management and the issue I emailed you about this week. That's a bit more tricky - as there's no clear example where core/native OT code will use an API endpoint that doesn't contain /api/....

    That said, clearly, if you were to write a widget that used a model tied to OTDS, the OTDS web services are on /otdsws/restapi - so the user.session.js code will block those requests - in short, any model based on a URL that doesn't contain /api/ is bound to fail.

    Hoping you might shed some light or your thoughts on that topic also ;)

  • @Ferdinand Prantl - FYI - the migration MD file is not in the SDK

  • @Ferdinand Prantl - Support ticket raised re the SDK/Generator per your suggestion. Ticket number 4825842. Initial response from support was effectively "you can download the SDK From....", though I was clear in the ticket and linked to this forum to describe problem! Reckon getting this one routed correctly may take a bit of back and forward.

  • Ferdinand Prantl
    Ferdinand Prantl E Community Moderator

    Spending a couple of e-mails with Custom Support is the only way how to request a fix in anything that OpenText ships, I am afraid. I am not aware of any dedicated Developer Support at OpenText.

    When you want to use a Backbone model, which does not connect to CS, and you want to use Connector, ConnectableMixin or other mixins that include the ConnectableMixin with it, you will need to carefully choose the authenticator. Some authenticators may be CS-specific and some may not allow enough customisation to authenticate with the OTDS REST API. I think that modelling an OTDSAuthenticator after the TicketAuthenticator might work.

    The RedirectingFormAuthenticator, which is an authenticator that you will most likely not want to use to authenticated OTDS AJAX calls. It supports automatic ticket refresh using a logging page, hidden (SSO) or visible (iframe with login form), and also the user session expiration warning since CS 21.2. Both of them require CS request handlers and will not work with other backend than CS. If you use this authenticator with the OTDS REST API, when the automatic ticket refresh kicks in, it will fail. The user session expiration support should not disturb, because it is optional. The check for "/api" on the REST API path is only to exclude some well-known CS REST endpoints from restarting the session expiration timer.

  • Ferdinand Prantl
    Ferdinand Prantl E Community Moderator
    edited May 24, 2021 #7

    On the second look I noticed that that you were right. The code is supposed to check if the current URL is included in a list of selected ones, but because of a missing check for "null" returned by a regex execution, it will throw an error unexpectedly.

    The CS CGI URL does not have to contain "/api" on its path. The code should not crash. I will file a bug about this, which should be fixed in CS 21.4.

  • Thanks Ferdinand - appreciated. IF you have a JIRA reference for the issue, please let me know - as I have an open support ticket on this matter, I can update them on that too ;)

  • Ferdinand Prantl
    Ferdinand Prantl E Community Moderator

    David, I filed LPAD-96116 about the unexpected error if the connection URL does not contain "/api". It wil be conencted to the support ticket 4825629.

  • Ferdinand Prantl
    Ferdinand Prantl E Community Moderator

    Content Server Smart View SDK 21.2 Patch 1 was released, accessible from Content Server Smart View SDK 21.2. The zip archives are supposed to be unpacked to the same directory as the original archives were unpacked to replace the original files. The patch archives contain patch.txt with the patch information. Then the original instructions should be followed.