Building custom UIs for Workfront with Fusion (part deux)

[#1]

Displaying Workfront Data

In the previous post, I described a super rudimentary way to use Fusion to generate a dummy page, and how to use that scenario's webhook URL to put that "app" into a dashboard as external page. 

Let's now use real Workfront data using that use case of displaying project documents under a program. The use case is that on any given project, the user wants to check if a certain document was already attached to the program or any project in it. If it exists, no need to recreate it.

Routing

But before we start the surgery, let's look at the current flow:

So we're going to expand the "set content" part, and because I dislike the mile-long scenario types, might as well think about routing at this point already, although not really needed yet. When I think of this I'd like to separate the "doing work" from the "send the response" part. Part of sending the response is the HTML wrapper, any Javascript etc. We make 2 branches:

Regardless of what the upper branch does, it will result in "output" - whatever the HTML content is. The bottom part gets this variable, it's also where we maintain the CSS and Javascript, and we combine everything into the HTML "template", zip it, and send it. 

Using Workfront data

This scenario will be used in a custom dashboard on a project/program and we want to list all documents found either on the program, or in all of the program's projects. 

So we need to give Fusion a tip where to look. We do this by adding query parameters to the "external page" URL.
Right now, the dashboard just has the plain webhook URL, something like: 

https://hook.eu.fusion.adobe.com/3q8247q7…brpvzqcwa

To this URL, we can add any query string we like, in this case we provide the ID of the current node, and the type of node:

https://hook.eu.fusion.adobe.com/3q8247q7xn...zqcwa?objCode={!$$OBJCODE}&ID={!ID}

 Side note: More on what params you can pass on WF docs, on Stackoverflow and on ExperienceLeague. 

So now we need to put together our document search. In English, we're looking for DOCU objects where

• If we're on a project: 
• projectID={!ID} OR
• project:programID= the programID of the project with ID {!ID}
• If we're on a program
• project:programID={!ID}

Here we have our first curveball: If we're on a project, we first have to get its programID. The benefit tho is that we have a simple search query: We only search for documents that are attached to any project in a specific program. Either we already have the programID (if the objCode is PRGM) - or we look it up based on the current project ID.

We use a branch to do the programID lookup if we're on a project, and set a variable with the result. In the bottom branch we get that variable, then do the document search, and finally set some output that we can see in the dashboard.

Here the scenario after surgery, and the example outputs when this custom dashboard is added to a project, vs. when added to a program:

On a project	On a program

The result is the same (it should be!) regardless where the dashboard is put. 

Let's take a look at the upper "Do Stuff" branch: First, we have the lookup for the programID - since we ONLY want to do this if we're currently on a project, we filter for objCode=PRGM.

 "objCode" is the parameter we added to the external-page URL, and the webhook receives it and exposes it as a variable.

Webhook exposes the query parameters as variables	We look for programID only if currently on a project

Side note: If you're impatient like me and don't want to hit the webhook to see the "1. objCode" variable, you can just type in Fusion expressions:
Here, I typed in 

{{1.objCode}}

The double-curlies mark this as a Fusion expression.

In the bottom branch we retrieve the variable programID - which may be set. If we're already on a program, it'll be blank because the upper path doesn't get executed due to the filter.

Onward to the actual search: I use a customAPI call because the regular search module wouldn't allow this exact search (you can only search by projectID).

We need to search arguments: DOCUs on the program itself, and DOCUs in any of the program's child projects. The programID might come from the webhook, or from the upper branch - so we just say "if one is empty, use the other". Since the ID in the webhook is always set (it's a projectID or a programID) we use it as the fallback argument in the ifempty statement. In English this means, "Use the programID from the lookup, unless that's blank - in which case use the ID the webhook received".

Finally we put together the output content, for validation purposes: 

In the next post we'll start making this a bit more useful, that is, we're going to display the 10 documents in a table. Meanwhile, the JSON so far. Hit me up if you have any questions to the above!

HTML page with Fusion2.zip ‏4 KB