/ Release  

Feel the excitement; AppWorks 23.2 is GA, and this post is updating you on the latest functionalities

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

AWP 23.2 is GA for Q2 2023. Grab your beer/wine (or whatever!?) and let’s have an update on the latest/greatest features!

Let get right into it…

The main installation menu is NOT updated; Why? Well after double-checking the ‘OpenText AppWorks Platform Supported Environments’ PDF, I conclude it was much faster to follow my own upgrade post. All related software still works with this version (compared with 23.1!)! A great choice as the upgrade (of CARS and the platform) took me not more than an hour of my time…Just between dinner and bringing the kids to bed. 😁 What about OTDS? Well, It just still works fine after my upgrade…Don’t touch a winning team! I know AWP 23.2 is delivered with OTDS 23.1, but OTDS 22.4 works smoothly with AWP 23.2 watching the support table in the documentation.

In this post we’ll review the AppWorks Platform 23.2 Release Notes. Have a look yourself at the PDF too; We’ll just dive through the latest futures delivered in this GA release.

🆕 Update on the available changes in 23.2 🆕

Let’s give it a go…But first we make sure we have a mail service container up and running! A first quick review on the release notes tells me a lot has changed in mail functionality. From a template perspective till a mail notification perspective on event subscriptions…So, we can follow our own blog posts on conquering this, but let’s make it as simple as possible this time! How simple? Well, as simple as smtp4dev. Holy crap…What a rush, what a relief, a savior of the dev-mail-world! The only thing is that we can’t receive mail, but for our feature testing it’s only required to send out mail…To this dummy SMTP server! In quick steps after you’ve started your AppWorks platform:

  • Download your package on your local laptop
  • Unzip it
  • Find ‘Rnwood.Smtp4dev.exe’ in the root, and double-click it
  • DONE…Owh, and tune your browser in to URL http://localhost:5000 for a simple receiver-client
  • In AppWorks (in your own organization), create a new service container from the ‘System Resource Manager’ artifact) with this input:
    • Connector type: E-mail
    • Group name: sg_email
    • Service name: sc_email
    • Mail server (Outgoing)
      • Host: IP/hostname of your local laptop; Should be reachable from your AWP VM!
      • Port: 25

That’s all, so no ‘Incoming Mail Server’ settings, no Mailboxes XML-config, and no DB-config either! It’s a party! 😍

You can evaluate your first mail call via the ‘Web Service Interface Explorer’ artifact with this SOAP request:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP:Body>
    <SendMail xmlns="http://schemas.cordys.com/1.0/email">
      <to>
        <address>
          <emailAddress>awdev@awp.com</emailAddress>
          <displayName>awdev</displayName>
        </address>
      </to>
      <subject>Hello world...</subject>
      <body type="normal">Nice...A body!</body>
      <from>
        <displayName>no_reply</displayName>
        <emailAddress>no_reply@awp.com</emailAddress>
        <replyTo>no_reply@awp.com</replyTo>
      </from>
    </SendMail>
  </SOAP:Body>
</SOAP:Envelope>

update_23_2_000

It’s not even required to make that ‘SetProfile’ service call as explained here! Why? Well because ‘smtp4dev’ an un-authorized service exposure…That’s why!

With this, easy, and most elegant solution up and running, we quickly dive into the first feature…

Creating and updating email templates in runtime

Interesting first feature; From a clean workspace and project I start creating a first entity. I name it todo with just a todo_name text property, making the default BBs nice, adding the ‘Email’ BB (with corresponding configuration in the configs folder of the project!), and we just add one ‘Email template’ with nothing fancy…Because we can! I also make sure to update the lyt_default with an ‘Emails’ panel next to the ‘Form’ panel, so we have something to play with in runtime! Comment me when this task is already a step too far as I would like to make hard meters this time as I’m a bit behind schedule! 😅

update_23_2_001

Deploy the entity, and have your first entity creation in runtime…Just with your (not recommended!) developer account for now. Before getting crazy and sending mails from this new entity instance, we first set the ‘From’ part in the ‘/app/admin’ section of our platform:

update_23_2_002

Now, embrace yourself sending a message to our ‘smtp4dev’ dummy server…It’s a green flag for me! How about the new feature for the part of the post!? I didn’t find anything related during my first mail message…Where can I find it? Well, looks like we need to move our ass to the ‘Lists’ panel of the homepage:

update_23_2_003

The difference between those 2 nodes:

  • End user email templates: Here your users can define new email templates and “see” the solution created templates as well when they have the checkmark Show this email template to end users
  • System email templates: Are the templates (maybe corporate templates!?) created in the solution but have an unmarked checkbox on the option Show this email template to end users

update_23_2_004

Creating new user templates makes it possible to set them ‘In draft’, ‘Active’, or ‘In active’; Well, the states speak for themselves. There is also a small nuance in “typing”. A runtime created user template is of type ‘Dynamic’ where the user templates published from the solution gets type ‘Static’. After I made my new template ‘Active’ it was possible to send out a mail based on this new template…Niceeee!

Notes during my journey on this feature:

  • Does the template support expressions in runtime? Yes, according to the documentation, but I didn’t find an expression editor on the runtime side…So, good luck my dear end-user; Maybe have that beer with your low-code developer to eventually help you along!? 🍺
  • Creating a template explicitly requires a ‘Save template’ button, so there is no auto-save like we normally see on an entity instance!?
  • On database level these templates are saved in table o2opentextentityruntimemodelsutilruntimeemailtemplate…Just so you know when your end-users get enthusiastic and overload your system with new templates! 🙈

Scheduling of email notifications

This must definitely be a user profile preference; Let’s go there in runtime (from your avatar icon) and check this view:

update_23_2_005

After this update, I will create some new instances of my brand-new entity! After 5 min. waiting…still no mail? Even not after following my notes from below (in this section)!? That’s a #RTFM as I see an error The [ GetOAuthConfig ] method is not supported for the given configuration passing by in sudo tail -999f /opt/opentext/AppWorksPlatform/defaultInst/Logs/Application_Server.xml. A quick ‘type’ change in my ‘Email’ service container solves this error from the logging with some dummy values:

update_23_2_006

It restarts my service container correctly, but sending a mail with the SendMail SOAP request fails with error Unknown oauth provider type! Which sounds logical for my dummy values! After too much of the time diving into the all the oAuth mail details I did a shout-out on the forum if this is really the way to go!? Let’s figure out this feature another time when we have a clear view on the configuration. The documentation, under section ‘Enabling notifications’ and ‘Facilitating collaboration’, explains some things but is not giving me a solid answer (yet!).

Notes:

  • The time selector “feels” new to me, not like other date/time selectors for a property…Or maybe it’s just me!?
    • I thought being smart, but the ‘Once per day’ will start the next day! Although I set it just 5 min. later from now…From a development perspective it’s better to have an “every 15 min. repeat” setting in place!
  • My first question would be: Who, what, or how is responsible for sending out the mails? Great question!
    • After you set your schedule a BPM is triggered (see the PIM) with name setUserNotificationScheduler running under your own account.
    • This will create a new schedule under the active tab or the ‘Schedule Manager’ artifact with name Notification_Scheduler_awdev@awp; Looks like each user will get its own schedule instance for this.
    • Ohw yeah, before I forget…Make sure you have the ‘Scheduling’ service container up and running in the ‘System’ space before you can even start with this all!!
    • I even set the log-level to debug on Scheduling, Notification and Email service containers to get better insights why things went wrong
  • The documentation also mentions a “secret” ‘ScheduledEmailNotificationConfig’ in the administration section of the platform for the solution OpentextEntityRuntimeModelsUtil; Set the ‘From’ and ‘Reply to’ here as well!
  • There is also the frequency ‘Default’!? This disables the scheduling part, but still sends you notifications…I guess based on what you configured in the ‘Notification’ BBs for your entities! Although…after double-checking the ‘Notification’ BB, it looks like the list of events in the user preferences are system overall and not specific to an entity. An interesting question would be: Do we need the ‘Notification’ BB on an entity to receive notifications or can we just sign up for global non-entity specific events? Continue reading as I get new insights during my own journey!

I moved back to the non-oAuth type of mail service which should be fine! Set up you own mail server from here

…

From an OTDS account perspective, I made sure to set the correct settings for a great experience in runtime (Like the firstname, lastname, and email)

update_23_2_007

Email notifications subscription

Well, this feature is partly “Busted” in the previous section…Check that first screenshot again of the user preferences where you have a full list available of selectable events. Looks like these are not entity specific events, but system global events. When I plot this on a use-case within my current project, I miss already a feature here; Add conditional events! So, when I pass a certain lifecycle state for a specified entity instance, I would like to get notified. My impression is that it’s not possible (yet!), but we’re on a good track. Lots of customers still would like to have mail notification in their inbox instead of monitoring the platform each day.

WAIT…Looks like I misunderstand the concept here! I think we DO need the ‘Notification’ BBs on the entities to send out the notification, but the end-user can choose in its user preferences to receive it by default (or scheduled…AHA!). Still, there is no possibility to add a condition as explained!? #FEATURE_REQUEST

Later on, we explore the enhancements for ‘Dynamic workflow’ BB; adding a ‘Notification’ BB on this related entity exposes events on ‘Workflow’ level…I never thought of it like this…Interesting!

New email features

This feature has a sub list of features!

Email attachments opened/preview on new tab

Attachment handling must first be enabled on the ‘Email’ BB; For incoming and outgoing mail traffic:

update_23_2_008

Once in place, you can add an attachment in runtime for a new mail:

update_23_2_009

After sending the mail you can view the attachment, but it’s more a download which was already possible. Maybe this feature is more about saving attachments separate as content, so you can view them in a separate browser tab with a <Ctrl>-click from the ‘Content’ panel or just mark it for the preview panel in your layout!? Comment me!

What I found interesting; And I see this over and over again! There is not always a consistent way of implementing things. Like for example the ‘Emails’ panel for a layout…Why can’t I checkmark an e-mail and have a view in the preview panel; You can only click it and get a modal popup? Why not add that same “feeling” like you do with a checkmark on a file from the ‘Content’ panel in your layout?

update_23_2_010

Define 5 email signatures (incl. a default signature)

A thing to do from your user profile preferences panel:

update_23_2_011

Notes:

  • The way of editing the signatures feels cumbersome for some reason…Maybe it’s me?
  • I can exceed the number 5 of my defined signature templates. I can also select them all from a new mail!? So, I don’t get the ‘five’ for this feature:

update_23_2_012

Email attachment size increased/controlled to max. 25Mb

I always thought this was controllable already on the related ‘Emails’ entity for your entity; When you open the related ‘Content’ entity for the ‘Emails’ entity, you can set the file size here…right?

update_23_2_013

After a double-check on the documentation, it looks like by default a mail attachment can only be 10Mb, but you can extend it to 25Mb in the wcp.properties; This is the flag for it: platform.entityRuntime.emailSettings.maxAttachmentsSizeLimit=25

Add current user emailID to “From” email address

That’s an option on the ‘Email’ BB:

update_23_2_014

In runtime, you’ll see it in the ‘From’:

update_23_2_015

Microsoft Graph global address book support as recipients (To. Cc. and Bcc)

This is pretty hard to try out for me as it requires me to have access to Active Directory settings in Azure to get a grip on oAuth data (client-id and client-secret) to make an API connection. So, I skip this one!

There is an interesting quote in the documentation (section “Configuring the E-mail connector”) which is not matching this requirement: GetFolders webservice in MSGraph does not returns default folders such as Tasks, Notes, Contacts, Journals etc. in the mail server.. To make this feature a happy conclusion it should retrieve the contacts…right? Or maybe this is done differently! Contact me if you have this feature available on your environment…I would love to have a techie-review together with you.

Typed REST API

This API, accessible via the ‘/app/admin’ portal or in my case via URL http://192.168.56.107:8080/home/appworks_tips/app/entityservice/aw_tipsaw_generic, is enhanced with ‘History’, ‘File’, and ‘Content’ BBs operations! So, when you add these BBs of your entity, it’s possible to have a view like this:

update_23_2_016

Enhancements for Dynamic workflow

Also, this feature has a sub list of features! Before diving in, I just clean all my mess crafted so far; So, I only have a basic entity again (incl. the default BBs).
With this in place, I add the ‘Dynamic workflow’ BB and attach myself to the correct role Workflow Template Administrator | Creator | Developer. I also update the lyt_default layout for my entity to show 3 new panels (‘Tasks’, ‘Workflow Instances’, and ‘Progress Bar’ for dynamic workflows!). Now we’re ready to create new workflow templates in runtime! Get yourself notified that the entity is now also applied a ‘Task list’ BB to low-code task type of functionality. Don’t go too far yet…I browse through it one by one…

Update the workflow initiator

For this feature, we add the ‘Assignee’ BB to the related ‘DynamicWorkflows’ entity:

update_23_2_017

In runtime, we now start a new workflow from our entity instance (you should have a ‘Start workflow’ button in the action bar for this when you have the correct role applied!) with a new static one-step flow like this:

update_23_2_018

For the demo, I also start a second one, so I can switch between instances in runtime.

update_23_2_019

Great, but how to “Open” or “Select” the workflow instance, so we can assign it to someone else? Well, after struggling for 30 min. (and still no answer!) I did a different approach viewing the dynamic flow layout!?…What I did is the following:

  1. Create a new layout lyt_default in the related ‘DynamicWorkflows’ entity which exposes the URL like this: start/web/#/item/080027008c65a1edbb930e17180d841a.<Id>. Well, actually it should be like this: start/web/#/item/080027008c65a1edbb930e17180d841a.<Id>.<Id>!
  2. To get the IDs, I get my developer tools <F12> ready in runtime with a view like this:
    update_23_2_020
  3. Moving my ass to this URL http://192.168.56.101:8080/home/appworks_tips/app/start/web/item/080027008c65a1edbb930e17180d841a.3.16387 gives me the possibility to ‘Forward’ or assign the workflow instance to someone else:
    update_23_2_021

So, jobs done!

After a quick review (I didn’t try it), it should be possible to make the re-assign possible from a ‘Task’ perspective. So, opening the task with a layout exposing related workflow instance data/actions!? I still find it cumbersome, but that might be my logic or still not understanding the concepts 100%!? Comment me!
WAIT…I just had my lunch-break and came to the brilliant solution to just create a ‘List’ BB lst_wfl_instances in the related ‘DynamicWorkflows’ entity! A much simpler approach, but still…My first project working with this ‘Dynamic workflow’ BB is still to come.
AND…Checking out my own post, we can add a ‘DynamicWorkflow’ grid on our form as well opening it from there…Well, that’s low-code…Multiple ways to Rome!

Dynamic workflow tasks can be approved or rejected

When you have a task configuration (on the related ‘LifecycleTask’ entity) like this:

update_23_2_022

…and in runtime you start a new dynamic flow dropping of a new task of this type, you will have the ‘Approve’ and ‘Reject’ actions available for your task:

update_23_2_023

Hitting the ‘Reject’ will get you to an interesting new modal popup for the next outcome:

update_23_2_024

Task names are now automatically filled with the task type

I already enabled this feature three screenshots back…Have a second look on the ‘Task configuration’! So, in runtime, creating a new workflow, the task-name is already filled for fast prototyping.

update_23_2_025

Completeness of a workflow

Quote from the documentation:

1
2
The workflow is considered complete only when all tasks (incl. the auto-complete 
tasks!) of the workflow are completed, approved, or acknowledged.

Well, should this not be the case already? It looks like the previous version of the feature skipped the auto-complete, and acknowledgement tasks. So, these types of tasks are included in the completion state now:

update_23_2_026

Transfer workflow to another user (on inactivity or deleted user)

❗❓ isn’t this the same feature as the first sub-feature “Update the workflow initiator“ ❗❓
AND
❗❓ to find them, matches the next, next sub-feature “Support for inactive workflows/tasks“ ❗❓

New status icons and updates in workflow summary panel

“Workflow summary panel”? Where talking the ‘Workflow Instances’ panel…correct? This thing:

update_23_2_027

Some notes should be in place before I get profounder:

  • Why is one completed task solid green and the other is not?
  • Why is there so much white space in the progress bar which you don’t have under control?
  • What is the logic behind these icons? The blue-icon is my completed flow, the green-frosty one is ongoing?
    update_23_2_028

It looks to me like we try to treat a multi-related entity in a single-minded UI!? I don’t know; It “smells” like a ‘Lifecycle’ implementation, but we hit the wall of multiple instances here and building our way out with dropdowns for switching it. It just feels like the implementation is not fitting the rest of the UI. Why not keep it simple and treat a repeating relation as a “repeating relation” with lists, grids, and repeating groups? When you mark an instance you can perfectly show a preview layout showing the correct data; When we can add a ‘toMany DynamicWorkflowTasks’ onto a form and can update its type to something new like “Task group”…How would that “smell” for a solution? 😎

Support for inactive workflows/tasks

Well, it looks like a customer (?) really wants to have more control on abandoned workflows and tasks. There is support for 3 lists which I understand concept wise:

  1. ‘All inactive workflows’
  2. ‘My workflow inactive user tasks’
  3. ‘All inactive user tasks’

Only, I have no idea who to implement them after looking for it…Let’s find clues, but please comment me!
Are we talking “template” workflows here or the instances of the template? The templates can indeed be made (in)active, and you can filter on it in runtime under the ‘Workflow templates’ node (for workflow admins). From a workflow instances point of view, it is required to create a ‘List’ BB on the related ‘DynamicWorkflows’ entity, but the states follow the states of a running lifecycle (see the CIM!) which don’t include (active|inactive).
There is an “old” artifact ‘Inactive Users Tasks’…Are we talking about this? I don’t think so!? Do we need to add a ‘List’ BB to the ‘LifecycleTask’ where we filter on ‘Task.State’?
How about ‘My workflow’? Are these the workflows “assigned” to you from the corresponding building block and can contain tasks where the user is made inactive? Or do I get a result of tasks (of inactive users) where the workflow is assigned to me?

Just a note for myself: In release 23.1 the feature “Inactive user task management for application users” explains $(deletedUsersWithTasks()) and $(disabledUsersWithTasks()) expressions for an e-mail template. I never tried them out myself, but they could have a connection with this feature…

Check for answers on this forum post as I’m lost as well!

Task/workflow related event notification will have a correct link to open them directly

I trust OpenText on their blue eyes that the link is solidly brought to our beloved end-users! 😇

Rebranding iHub to Magellan Business Intelligence and Reporting

Is it a fully, fully rebrand? Or a fully rebrand? I know in my current project there is also some refactoring done, but not fully, fully! What is the difference? Well, consistency! You can rebrand labels and icons as nice as possible, but if you don’t rebrand the technical principles behind it, it will haunt you down until it’s been done. I know from experience; Especially when your developers circulate in the team! Let’s first see what has changed, but also have a look on the other side of the medal.

There it is…Shining in the middle. My first opinion is the high contrast over the other icons, but this is only for designers…right?

update_23_2_029

The service container connector is indeed renamed:

update_23_2_030

The entity layout panel is renamed:

update_23_2_031

Also in runtime:

update_23_2_032

As well as in the administration portal:

update_23_2_033

…

What can we still find on ihub for the platform:

On the server, I can still see /opt/opentext/AppWorksPlatform/defaultInst/components/ihubconnector.

Have yourself also a search on the server (Ohw boy!):

1
2
sudo find /opt -type f -name *ihub*
sudo grep -rnw '/opt' -e 'ihub'

In runtime the developer tools still show iHub stuff:

update_23_2_034

In design time the developer tools still show me this:

update_23_2_035

The ‘XMLStore Explorer’ artifact still shows the good old CAF file:

update_23_2_036

A view in the ‘Webservice Interface Explorer’ artifact:

update_23_2_037

…

Conclusion? Looks to me there is still enough work to do…Is this a fair conclusion!? In my opinion it is, let’s see how this keeps standing after 5 years and scrambling the development team upside down! Well, I know the outcome already in lost time and unclear communication.

Save email to Content Server with type email

I don’t have OTCS up and running to try this out, but I can remember the discussion already from my 2 previous projects! For this feature we can set a flag in the ‘wcp.properties’ file: platform.entityRuntime.emailSettings.emailMessageType=true

By default, a mail is saved as ‘Document’; With this flag it’s saved as ‘Email’. This is now available for OTCS; Was this setting already available for Documentum? Please, comment to me…

See also the documentation under section “Providing email functionality”

Configure the author details for discussions

For this we add the ‘Discussion’ BB. Under the advanced configuration for this building block, we can open the related entity with this configuration part:

update_23_2_038

An interesting observation: The ‘Discussion’ BB has a related ‘Discussions’ entity! I see this also for the ‘Content’ BB with a related ‘Contents’ entity. Are these valid names for entities? I had this conversation before…I think an entity can never have a name which intents it’s multiple instanced. So ‘Discussion, and ‘Content’ as entity name would be better; In my opinion, but comment me if you don’t agree with me?

Save list filter configurations in user preferences

It looks to me like the filter options are in more control to the end-user:

update_23_2_039

Also, that ‘My saved filters’ is collapsible. When you also define filters in the ‘List’ BB they will be available in the ‘Views’ dropdown, but that’s a feature already available in previous releases!

Disable layout panels using rules

Is this the end of creating ‘ReadOnly’ forms (a copy from a normal form) in our solutions? Ohw yeah…It is!! How? Well, create yourself a new ‘Rule Category’ BB with name rc_read_only. Next, create a new ‘Rule’ BB with name e_onpropchange_read_only. Set the advanced condition to true and make sure to set a ‘Disable’ action for the rule category. The final thing is setting the rule category to the panel in your layout:

update_23_2_040

In runtime, the form is nicely grayed-out on the property fields without manipulation each field with a ‘Read only’ flag on form level…NICEEE!

Improved performance for Entity and Rule designers

Maybe it’s a placebo effect or maybe my project is just too small, but it “feels” faster on loading entities in design time! I trust OpenText on their blue eyes it’s made faster. In my current and larger entity project opening entities takes ages and developers complain about it. So, I hope an upgrade is planned soon for our project to move to 23.2 to get this issue solved on entity loading level.

For a try-out I made an SVN copy of my current project and loaded it with a workspace sync into AppWorks. The entities load much, much faster, but I must say that we’re now locally on a laptop VM without any SVN/GIT connection! It’s also good to know the upgrade from this SVN copy (AWP 21.4) went smooth after setting the correct permissions on server-level these commands:

1
2
sudo chown tomcat:tomcat -R /opt/opentext/AppWorksPlatform/defaultInst/cws/sync/appworks_tips/ws_aw_tips/
sudo chmod 777 -R /opt/opentext/AppWorksPlatform/defaultInst/cws/sync/appworks_tips/ws_aw_tips/

Comment me if you don’t have a clue about synchronizing a project like explained above…

JavaScript APIs for AppWorks Platform client operations

There is indeed a new operation:

update_23_2_041

This is the syntax using it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
publicAPIProvider.createAndLinkChildToParent(
  {
    "itemId" : "{itemId}",
    "relationName" : "{relationName}",
    "properties" : [
      {
        "name" : "{propertyName}",
        "value": "{propertyValue}"
      },
      {
        "name" : "{propertyName2}",
        "value": "{propertyValue2}"
      }]
  }
);

Also, the ‘navigate’ method has support for the ‘Reusable’ type of homepages:

1
2
3
4
5
6
7
8
9
publicAPIProvider.navigate(
  "{itemId}",
  {
    "layoutId": "{layoutId}",
    "clearBreadcrumb": true,
    "breadcrumbName": "{newName}",
    "type":"reusable"
  }
);

Support for entity layouts in the layout panel

This is an option in the ‘Layout’ panel for an entity layout:

update_23_2_042

Now we can also select current entity layouts (except itself…dûh)! In previous releases we didn’t have this checkbox, and we could only select homepage type of documents configured as ‘Reusable’; So, like this:

update_23_2_043

Support for OAuth delegate authentication in Microsoft Graph mail protocols

Well, nothing more, nothing less:

update_23_2_044

You know what to do with it when you’re the MSGraph connection guru!

Automatic creation of organization in container-based deployment

I still didn’t get the time for myself to dive into the container-based deployment without drowning. For some reason, my swimming straps snap when I’m almost reach the other side of the sea! It’s on my backlog for another try…

What I did do is scanning the ‘OpenText AppWorks Platform 23.2 Cloud Deployment Guide’ PDF on how this feature is configured. Looks to me that it’s part of the MicroProfile Configuration (MPC) for a Docker image! A what? Yes, that’s why I probably drown every time. It “smells” like this (comment me when I’m totally wrong here):

  1. Download the AppWorks containerization package
  2. With Docker compose you can create new AppWorks platform images (well, I think multiple images from what I understand in my previous try-outs)
  3. An image is just a template on which you can create new containers landing on your preferred system; locally via minikube, or in a cloud like Azure, AWS, or GCP; That’s a choice for you to make.
  4. The template images get an MPC file (settings-all.yml). In this file you can make the create-organization-feature setting for your container:

update_23_2_045

From my last discussion with an insider it’s also possible to deploy solution specific containers where your crafted CAP files are directly in place for end-user consumption. The power here is not delivering a CAP file to TEST, but delivering a container to TEST! A quote from the Netherlands (in my native dialect): Het kost wa, maar dan hedde ook wa! 😜

Integration with Core for Signature

I’m not privileged to make a full eSig implementation, but I can for sure guide you the way…
First of all, you need to make sure having an ‘E-Signature Configuration’ like this (It’s a dedicated artifact in design time):

update_23_2_046

Notes:

  • eSig base URL is always the same: https://sign.core.opentext.com
  • “Site ID” equals the “Tenant ID” which you can find in your Core admin center; This is the URL to Admin Center
  • In ‘Admin Center’ you can also create a new set of ‘API service credentials’ (that’s your clientId and clientSecret!)
  • The authorization endpoint has the tenant id applied: https://otdsauth.ot2.opentext.eu/otdstenant/{tenant_id}/login
    • Watch also the .eu instead of the documented .com!
  • This is also documented in the admin guide; section “Managing E-Signature configuration”
    • Here you also find the “polling/async” part if you don’t have your AppWorks URL publicly available for Core for Signature (eSig!)

With this configuration ready, you only need to add the ‘File’ BB (or ‘Content’ BB) and you will have action buttons in runtime available to make a signature call for the selected document. To see what is available, I just add a ‘Security’ BB which tells me this:

update_23_2_047

If it’s an inline experience or a new tab/window is unclear. The documentation talks about “the Signature request window will open”…Comment me if you have it up and running; I’m curious having a demo from you in relation with AppWorks; I already saw a demo of “Core for Signature” itself.

NOTE: eSig is supported for all supported content systems except platform repository! So, you need a valid ‘Documentstore’ connector with a relevant service container up and running. Things we explained already for OTCS and DCTM.

Integration with Intelligent viewing

It’s been a while ago having a check on the ‘Intelligent viewing’ software package. During that time, I can remember this quote: 

1
2
3
4
5
What about the fancy features like 'Redaction', 'Annotation', and 'Comparing'? 
Well, those need to be enabled from the ‘Security’ BB of the entity. 
Only from OT support I retrieved (in that moment in time) information that our AWP 
only supports the ‘viewing’ part of IV which is sufficient for our post this far. 
Keep yourself informed on the new IV releases for an update on these topics!

Well, here is your update on what is currently possible with IV on our beloved platform:

  • View documents
  • Compare documents or versions
  • Search (in content) documents
  • Annotate documents
  • Redact documents
  • Publish documents

Administrators can configure markup and highlight services of IV in AppWorks Platform along with viewer and publication services. It’s all based on licenses, so reach out to your sales representative to get it. The AppWorks Suite installation is delivered with the IV package and includes a limited license file INTELLIGENT_VIEWING.lic.

You can find my ‘Intelligent viewing’ journey behind this tag.

CARS upgraded to CARS 2.8

A direct quote from the documentation:

1
2
3
4
OpenText CARS version is upgraded to 2.8 with the latest version of OpenLDAP and 
OpenSSL, which addresses many security vulnerabilities. AppWorks Platform 23.2 
works only with CARS 2.8 and customers who are upgrading from earlier versions 
of AppWorks Platform needs to upgrade CARS.

Setting permissions for business workspace when an item is shared to a role

It’s not worth my time trying it out currently (as we need an OTCS with xECM connection up and running!), but let me explain what is going on for this feature in plain text. From an AppWorks perspective it’s possible to share an entity instance to a user or role; We have the ‘Sharing’ BB to accomplish this feature. When the entity instance also has a ‘Business workspace’ applied (configured via the ‘Documentstore’ connector in AppWorks) you need to have a mapping between the instance role in AppWorks and the team role in xECM to glue it all together on security level. For user-sharing this was already working fine, but now it’s also possible to share on role level (be it an application role or organization role in your solution) and have the corresponding group in xECM added and mapped to the related team role.

NOTE: The same roles must exist both in AppWorks and in xECM which sounds logical to me!

Deprecated features

NONE! 😊

That’s it…AppWorks playground 23.2 is open and ready to build/upgrade your solution. It’s a ‘DONE’ from my side on this update post with a great overview of the new GA features for this Q2 2023 release. I see you in the next post…Have a good low coding weekend!

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?