Best Of
Re: Is Cloud Fax and RightFax the same?
Hi,
RightFax does have an API but like you, I can't find any reference to it since the website redesign.
If you find something, please post a link, and I'll do the same.
Good luck
Re: Smart UI commands - implementing the open classic view example
Hello Hugh,
From what I understood, you have an existing Smart UI extension (let's call it hugh 😉) and want to add a new command in there, but it's not working. The command never shows.
I'm not sure what's wrong, but for a command to actually show somewhere, you have to do a few steps:
- Create your command code (copy from SDK or make your own)
- This means ****.command.js, which extends CommandModel
- Plus a ****.nodestable.toolitems.js file, (which you pass to the nodestable widget using hugh.extensions.json later)
//open.classic.nodestable.toolitems.js define(function () { 'use strict'; return { // "otherToolbar" here stands for one of the nodetables toolbars. // There's also an "inlineActionbar", which shows when you mouse over a row otherToolbar: [ { signature: 'OpenClassicCustom', // Must be same as the command signature name: 'Open Classic Page' } ] }; });
- Add the two .js files mentioned above into your src/bundles/hugh-all.js
// Placeholder for the build target file; the name must be the same, // include public modules from this component define([ 'hugh/commands/open.classic/open.classic.command', 'hugh/commands/open.classic/open.classic.nodestable.toolitems' ], {}); require([ 'require', 'css' ], function (require, css) { // Load the bundle-specific stylesheet css.styleLoad(require, 'hugh/bundles/hugh-all'); });
- Add the files into your src/hugh-extensions.json
{ "csui/models/server.module/server.module.collection": { "modules": { "hugh": { "version": "1.0" } } }, "csui/utils/commands": { "extensions": { "hugh": [ "mps/commands/open.classic/open.classic.command" ] } }, "csui/widgets/nodestable/toolbaritems": { "extensions": { "hugh": [ "mps/commands/open.classic/open.classic.nodestable.toolitems" ] } } }
- run grunt and copy the out-release contents into your OTCS/support/hugh folder on the CS location
- The command should now be showing inside the nodetable's top header (after you select an object using the checkbox in the leftmost column)
Can you check you got all these steps?
Other useful information:
- The open.classic.command has no enabled method, because it "inherits" it from CommandModel
- 'open.classic.command' extends 'csui/utils/commands/open.classic.page' which extends 'csui/models/command' which has the default enabled implementation hidden inside.
- It's actually possible to test and develop commands using the local server in the extension, but it takes some test/index.html setup
I've ran out of time, but I hope you have good luck with solving your problem.
I remember how happy I was when I finally managed to get the open.classic.command working for the first time 😅
Javascript Sample to demonstrate managing the lifecycle of your application
As a developer on OpenText Cloud Platform, the lifecycle of your application can be represented by the flow above. You deploy your application; when they sign-up you provision your subscriber; your subscriber adds users to the application and then they use the application. The Develop Application step is really just a special iterative case of all the other following steps and so this article will follow the flow from Deploy Application onwards.
OpenText has now provided an open source Javascript sample which implements this flow using the Developer Admin API (see here) and the sample can be downloaded from Github here. Additional information on working with Developer can be found here.
Managing all of this are a number of key concepts:
- An Organization is your business account within a Region
- The Org owner is a Developer who is authenticated with the OT platform using our OT Connect customer system
- The Developer creates multi-tenanted apps owned by the Organization
- Organization creates, owns and manages tenants for application subscribers
- A Subscriber’s tenant is subscribed to the developer’s application
API Authentication
For secure API access from your application to the platform to perform these management actions you will make use of two different Oauth security schemes or contexts:
- The organization security scheme is for APIs which manage Org owned entities – the entities you own – the Organization itself, your applications and your subscriber tenants
- The tenant security scheme is for APIs which manage Tenant owned entities – Tenant or Subscriber owned entities such as users, which applications they use and how they are authenticated AND the sandboxed information management service API calls made by users - e.g. to content storage, workflow, etc.
The Developer Admin API documentation here covers how to authenticate with the platform using these two security schemes. The sample application provides implementations of these two security schemes to gain the required access tokens for the proceeding API calls in the sample.
Retaining IDs
When performing the above lifecycle for real you will need to maintain key entity IDs returned in responses. You will retain these as references within your application database. These references are UUIDs generated by the platform. Examples are:
- applicationId
- tenantId
- authenticatorId
- userId
The sample webapp presents these ids in the response data within the UI from where they can be copy and pasted into subsequent requests within the webapp.
Deploy Application
Assuming you have successfully developed and tested your application, the first thing you’re going to need to do is deploy your application.
There are two steps to this:
- Creating the application
- Configuring the callback URL for your user authentication flows
All of this can be done via the Console UI as it is an infrequent activity but the sample app will show how you do it with API calls using the organization security scheme. Within the sample webapp, steps 1 & 2 are performed from the Organization page.
Provision Subscriber
Having deployed your application onto the platform – you now need to provision a subscriber to use the application – and you’ll do this each time you on-board a subscriber. Within the sample, steps 1 & 2 are also performed from the Organization page of the sample webapp.
There are three core steps to provisioning a subscriber:
- Provision subscriber sandbox – in OpenText terminology, the tenant
- A tenant provides full isolation between subscriber data
- Only tenant users can be given access to the tenant and its data
- Provision your application to the newly created subscriber tenant
- Users are given access to applications and their data via a tenant with which they authenticate
- Multiple applications can be provisioned to the same tenant
- Set-up external identity provider, which is your application or an IdP you application uses, for tenant users, in OpenText terminology, authenticators
The sample application shows how steps 1 and 2 are performed via API call within the organization security scheme. Within the sample, steps 1 & 2 are also performed from the Organization page of the sample webapp.
Step 3 is performed using an identity authenticated using the tenant security scheme. Within the sample, step 3 is performed from the Tenant page of the sample webapp. However, since most, if not all your users will use a custom rather than the built-in platform authenticator then you will create the authenticator before you create users, and so the order above represents the order you are likely to perform subscriber provisioning.
Add Subscriber Users to Application
There are two simple steps to this - and you'll do this each time you onboard a new user for a subscriber:
- Create the user within the tenant/sandbox
- Add them to the application
The sample application shows how steps 1 and 2 are performed via API call within the tenant security scheme. When the user is created the request body of user meta-data contains the authenticatorId of the external authenticator (IdP) configured for your application. Within the sample, steps 1 & 2 are performed from the Tenant page of the sample webapp.
Use the Application
Having done all of that - your users are now in a position to login and use your application – but in order for that to work there are a number of key requests each time a user logs-in:
- Authenticate the subscriber user using your identity provider, using the authenticator previously configured for the user. The sample shows how this can be done from a Single Page App (SPA) – a public or untrusted Oauth client - using Auth Code grant flow with PKCE
- Authenticate the user against IdP using their authenticator and obtain an Authorization Code
- Exchange the Auth Code for an Access Token to OT platform and get back other tokens in the response
- Call the required Information Management APIs as the user in the context of the subscriber’s sandbox/tenant using the Access Token
The sample web app shows how step 1a is performed via a browser request and step 1b via API call within the tenant security scheme. Step 2 is also uses the tenant security scheme using the access token obtained in step 1b. The sample webapp illustrates Step 2 through API calls to the CMS API to upload and download a JSON document.
Within the sample, steps 1 & 2 are performed from the User page of the sample webapp.
Re: Tutorial - Sample App for Contract Approval
Watch the complete session from OpenText Developer Summit!
Learn the foundations and basics of our Developer Services and learn how to register, build an application, authenticate your token, and use services such as Content Storage, Content Metadata and Workflow. This video is ideal for those wishing to start a journey within the Information Management (IM) space.
Watch this video and follow the step-by-step instructions and guidelines of our experts on how to use the services for the first time. Developer Services and API calls can be easy to leverage by simply following the steps shown here and you will be surprised on the applications you can build in just a matter of minutes.
White Paper - Technical Overview of the Platform
OpenText IM Services Fundamentals
Technical overview of the platform
The platform is purpose-built for delivering Information Management applications and services in a highly secure and highly available multi-tenant architecture.
This white paper outlines the platform’s key design characteristics including its infrastructure components, platform tools, tenancy model and administrative functions. It also describes the SLAs that govern operation of the platform.
Security of content, transactions and access is an essential element of the platform’s design. This white paper describes the platform technology that secures and protects content and communication, and the additional compliance and governance measures in place on the platform to further protect customer content.
Topics covered:
- Tenancy and Concepts
- Platform Infrastructure
- Service Level Agreements
- Secure Communication and File Encryption
- Admin Center
- Compliance and Governance
Discuss with the community:
Click here to go to the IM Services area of the community
Re: eDOCS REST API
Thank you for your patience.
Here is the eDOCS API, there is also a link to "Additional Docs"
Re: Developer Summit - Workflow Service Lab
Yesterday we had the pleasure of hosting one of the first developer labs of the Partner/Developer summit where we took students through a series of steps that resulted in them building and testing their first application powered by the OpenText Developer Cloud. Students started by signing up for a free trial (if they had not done so previously), they then defined a Contract document type definition in our Content Metadata Service and a Contract Approval workflow in our Workflow Service before going on and testing it in a pre-built React/Node application which we provided. As expected this was a lot to do in just 60 minutes and not everyone was able to complete the whole lab in the time, but the students were able to continue on their own after the allotted time was up.
If you are attending any of the other days this week why not join us for either of the repeat labs #103 or #104.
The good news for those of you who are not able to join us is that we will be making the materials available in the form of a full tutorial very soon including the sample application that you will be able to run locally, to get the full experience from the comfort of your own favourite developer chair!
Nick King - Director of Product Management for the Workflow Service