/ Development  

Extend the 'Used by' functionality with a source search in your IDE

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Maybe you recognize this question after you renamed a property on an entity: ‘Where else in my solution did I use this property and will it “hit the fan” somewhere when I change it!?’

Well, I recognize it by myself, and the platform has a nice feature called ‘Used by’, but let me tell you upfront, it will not expose all in-depth details! Especially when you’re in the scripting mode and use regular expressions!

Let’s dive into some samples where the ‘Used by’ will fail and let’s see what another valid solution might be to expose ALL used locations.

Let get right into it…

For this post I suppose you have something nice already created as a solution. If not, you just craft something yourself. At this moment you should be able to just create some ‘Todo’ entity which starts a lifecycle and has some building blocks applied to it. Have also some action rules applied which starts some BPMs to play around with. We’ll also expose some services to see what’s happening on that side. From the runtime perspective…WAIT…For this post we don’t need any runtime as we purely focus on design-time changes and the surrounding refactoring.

Use the ‘Used by’ function

So, let’s first start with the regular ‘Used by’ functionality. The action can be found when you right-click any project, folder, or document within the solution:


When you hit it, you’ll get an overview where the selected item “is used” within the solution. With a small solution like my screenshot, you’ll probably know where things can be found. Only, once a project increases in size this feature can bring light into the darkness to keep track of things and how they are related to each other.

Some samples:

  • The ‘nl_NL.png’ icon tells me it is used in the ‘homepage’ document
  • The ‘dummy_bpm’ BPM tells me it is used in the ‘dummy_bpm’ webservice and in my ‘todo’ entity lifecycle BB
  • The ‘todo’ entity tells me it is used in the ‘dummy_bpm’ BPM by an ‘Update’ webservice call
  • the ‘f_tester’ role tells me it is used in the ‘todo’ entity security BB
  • the ‘mail_config’ document tells me it’s also used in the ‘todo’ entity mail configuration BB

So far, so good; On folder/document level we are pretty good, but what about:

  1. …(specifically) a property name on an entity? Where is it used in our solution and what do we need to update when it changes?
  2. …a BPM activity mapping where we use some xPath expression based on low-code configurations?
  3. …a security condition where we use expressions based (again) on low-code configurations? Remember? item.Properties.todo_name=="test"
  4. …the same for a Rule BB condition!
  5. …what about a homepage action (external URL) based on low-code configurations? Remember? http://www.myurl.com/{item.Properties.todo_name}
  6. …or a filter on a result list (in a layout panel) which points to low-code configurations? Remember? Properties.Type={item.Properties.Type}

These are all questions where our next section will start!

Explaining some samples

Firstly, let’s extend our solution with some scenarios to search on like described in the previous section. We will misuse a property ‘todo_name’ on the ‘todo’ entity, and we make sure to use it in several locations:

Adding a Rule

This will start a ‘dummy_bpm’ when to ‘todo_name’ property equals ‘BPM’. Like this (with Rule name e_on_create_start_bpm):


Updating the security

I have already a security BB applied to my entity with some marks to play around. We just add an extra condition to the ‘Delete’ action of the entity. Just an extra check our ‘todo_name’ must be filled with a value ‘delete’. Like this:


The condition looks like this:


BPM entity service call

Our ‘todo’ entity has all the CRUD operations available via the ‘Web service’ BB. Now that we have a ‘dummy_bpm’, we can also do an ‘Update’ call to set our ‘todo_name’. Like this:


This is my BPM (clean and simple):


The filtered result list

For this we jump into the generated ‘DefaultLayout’ of the entity where we have something available like this (you can add any missing panels yourself…correct?):


We are required to select an item for the ‘Results’ panel, and we are also able to add on extra filter to it. The filter will look like this: Properties.todo_name='filtered'

Make sure the ‘todo_name’ property of the entity is also available as column in the corresponding “All todo items” list!

The homepage creation

I already have a ‘homepage’ document available in the ‘homepages’ folder of the project to misuse, and we just add an action (available since 21.3) to it with something like this:


I know…It’s not possible to make this a workable feature as we’re not ‘In context’ of the ‘todo’ entity. This example it just for demonstration to get some interesting search results later on!

Now, let’s save all the changes and leave it as is. There is no need to publish anything as we just want to figure out where our ‘todo_name’ property “is used” at the moment. We now pick this example, but the below trick will off-course work for anything within your solution!

So, we just saw some samples passing by, now we get the request to update our ‘todo_name’ property (or maybe delete the property)! Now for that great question: ‘Where did we use it?’. In this example it’s pretty easy, but how about you’re asked to make this same change in a solution which is developed for several years with multiple developers!?

Well, the answer is not that hard, but we need to dive in the generated low-code sources. Before we can do a search on that property name, we first make sure our low-code ‘sources’ are synchronized to a file store. In my case the VM file store where I installed the platform. To make this happen, we right-click our project and hit the ‘synchronize’ action from the menu.


What does it do? Well, have a look in this location of the server (for my specific project!):
sudo ls /opt/opentext/AppWorksPlatform/defaultInst/cws/sync/appworks_tips/aw_dev_ws/generic

When you browse through it, you’ll see it’s just a bunch of XML data (or CWS data) which represents the ‘sources’ of our low-code craftmanship!

So, now what? Well, how about a quick search directly on the VM?

sudo grep -Ril "todo_name" /opt/opentext/AppWorksPlatform/defaultInst/cws/sync/appworks_tips/aw_dev_ws/generic

#Resuls to this list:

Or a search to ‘look into’ the content, like this

sudo grep -rnw '/opt/opentext/AppWorksPlatform/defaultInst/cws/sync/appworks_tips/aw_dev_ws/generic' -e 'todo_name'

The first command will give a nicer overview as we can clearly see all the documents and BBs where our ‘todo_name’ property “is used”! We can now just open the corresponding document in design-time and tackle it. If you still can’t find it, it’s also possible to just open the .cws file and have a closer look. These files are just plain XML files which can be searched from every basic XML editor!

Just be sure to not update these files as they are generated be the platform. Wrongly edited source files can seriously break your solution!

It’s also pretty interesting to have a look at the structure on these source files. It gives a better feeling what happens in the back-end of our low-code platform.

We now just search directly on our VM, but it’s also possible to make a copy to your local laptop and so a search with your own favorite tool. Like for example IntelliJ IDE, or just Notepad++. This also brings us to another way to search in this content! How? Well, how about a project which is connected to an SVN source control system!? Exactly those same sources are available from that location! What keeps you from checking out the low-code sources from that SVN location to your local system and have a search again!? Also, with your own IDE!

Of course that same note to not update any SVN generated sources directly outside the low-code platform. It can (again) seriously break your solution.

Interesting knowledge exposed again (I give it a “DONE”) on how to extend the ‘Used by’ functionality when you’re in refactoring mode. It’s also nice to see how back-end “source code” is generated on our beloved low-code platform. It gives valuable insights and can (sometimes) give you just that bit of missing information you were looking for. Have a great week with your low-code “sources” exploration, and I see you in the next post.

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”?