We continue our series of interesting support questions to help you customize your EvolutivoFW application.

When the user is executing a series of steps in a business process. How can I show them what step they are on?

There are three ways to accomplish this.

1.- Business Process Perspective This is an advanced set of modules and configurations to help users go through the steps of a business process. It uses actionable Mermaid graphs to show the user what step he is on and where he can go next. It supports VERY complex business process automation and is very well documented in the Process Flow Perspective repository and the documentation wiki.

2.- Mermaid Business Questions. The mermaid business question type supports customizing mermaid graph nodes depending on the values of the fields in the current record. Using that functionality we can show a mermaid graph that shows the current stage in the business process easily. This is explained in the Business Question Mermaid Graphs section of the documentation.

3.- Path Widget. Also based on the business question module we have the Path type which will show a one line path widget with the steps done, the current step and the steps that are pending.

The first configuration is to define the Business Question record with the type of "Path", and its properties field to be a JSON object indicating the steps name and value, like this;

{
    "nodes": [{
            "nodename": "Step1",
            "value": "Prospecting"
        },
        {
            "nodename": "Step2",
            "value": "Qualification"
        }, {
            "nodename": "Step3",
            "value": "Needs Analysis"
        },
        {
            "nodename": "Step4",
            "value": "Value Proposition"
        }, {
            "nodename": "Step5",
            "value": "Id. Decision Makers"
        },
        {
            "nodename": "Step6",
            "value": "Perception Analysis"
        }, {
            "nodename": "Step7",
            "value": "Proposal/Price Quote"
        },
        {
            "nodename": "Step8",
            "value": "Negotiation/Review"
        }, {
            "nodename": "Step9",
            "value": "Closed Won"
        },
        {
            "nodename": "Step10",
            "value": "Closed Lost"
        }
    ]
}

Then we have to create a Business Action of type DETAILVIEWWIDGET, setting its Link URL field to the value that loads the PathWidget and defines the question ID and the target field to read the values from:

block://PathWidget:modules/cbQuestion/PathWidget.php:targetid=$RECORD$&qnid=45549&targetfield=sales_stage

• qnid needs to be matched to the question created before for the path widget
• the targetfield should be the field which we will read values from in the record

A perspective is a set of code and database changes that literally convert a stock Evolutivo system into a verticalization prepared for a clearly defined market segment.

Hi Joe,

I am starting to work on perspectives as we need one for a client.

I saw in the documentation that you have already created a way to apply many changesets with the cbPerspective module. I installed it through composer and I saw that two changesets were applied. But I don't understand quite well how it works. For example if I want to use it for 2 different perspectives that need two different sets of changesets to be applied, will I have to create two cbPerspective repos each one containing a set of changesets?

And have you done anything to put a perspective into a single repo? Let's say the Telemarketing perspective repo contains two modules to be installed and 3 changesets.

Before seeing the documentation I was thinking of creating a repo with a folder 'modules' containing all modules/extension to be installed, a folder 'manifests', containing manifests of each module, a folder 'cbupdates' containing the changesets etc. And than I would have to add a new method in the ComposerInstall.php file to read and install each module separately and to install the changesets. But now with the addition of the cbPerspective extension I am a bit confused on how to integrate it in a single repo.

The fundamental part of a Perspective is the composer.json file and the ComposerInstall project

Using composer with a specifically crafted composer.json file you can install as many modules as you like. The idea is that you will have each module in it's own repository, you will define the composer.json file to connect to each one, download it and install or update it accordingly.

So using composer we can install all the modules we need. Additionally, we need two more things to convert a stock Evolutivo into a verticalization:

• one or more database changes to tie all the modules together. each module will have installed what it can in its postinstall, but there will always be some steps that need to be taken once all the modules are installed
• patch the base files. Ideally, this would not be needed, but each client has their own needs....

In order to apply the final set of database changes I created the cbPerspective extension. That will permit you to create some Evolutivo updater changsets and group them together in a final install step. So, the goal of cbPerspective is not to be used as it is in its repository, but to be customized for each verticalization. In other words, you will have a TelemarketingPerspecitve extension, in its own repository which will be a copy of cbPerspective with a set of Evolutivo updater changesets to be applied after installing all the new modules.

With that extension created and composer you will be able to install all the new modules and make all the post-database changes you need, both on install and on update:

composer install

or

composer update

both will work.

For example, this is a composer.json perspective file:

{
  "repositories": [
  {
    "type": "vcs",
    "url": "file:///home/joe/reps/ComposerInstall"
  },
  {
    "type": "vcs",
    "url": "file:///home/joe/reps/adocDetail"
  },
  {
    "type": "vcs",
    "url": "file:///home/joe/reps/adocMaster"
  },
  {
    "type": "vcs",
    "url": "file:///home/joe/reps/coreBOSPackingSlip"
  },
  {
    "type": "vcs",
    "url": "file:///home/joe/reps/coreBOSEmployee"
  },
  {
    "packagist": false
  }
  ],
  "require": {
    "tsolucio/ComposerInstall": "dev-master",
    "tsolucio/coreBOSPackingSlip": "dev-master",
    "tsolucio/adocDetail": "dev-master",
    "tsolucio/adocMaster": "dev-master",
    "tsolucio/coreBOSEmployee": "dev-master"
  },
  "scripts": {
    "post-install-cmd": [
        "tsolucio\\ComposerInstall\\ComposerInstall::postPackageInstall",
        "php modules/cbupdater/loadapplychanges.php modules/ConfigEditor/composer.xml"
    ],
    "post-update-cmd": "tsolucio\\ComposerInstall\\ComposerInstall::postPackageUpdate"
  }
}

If you feed this composer.json file to composer from the top of an Evolutivo install you will get coreBOSPackingSlip, adocDetail, adocMaster and coreBOSEmployee modules installed in one step. If one of those modules were a cbPerspective extension it would have been installed with all the rest and would have launched it's updater changesets. So all you have left is to apply any specific patch to the base code to get your verticalization.

Now what has really happened is that, although this seemed like a good idea at the time and we dedicated a lot of effort to it, maintaining a whole bunch of separate modules is hard work. For example, once you apply the perspective, you commit all the new code, you put it into production and you find an error in one of the modules, so you fix it, get the patch and update the module in its repository and then launch "composer update" to bring in the fix from the repository but that also updates the files in another module which you have customized for this client, so you have to undo that change before committing the fix into production: tedious, too complicated. So you end up having repositories for each client with their fixes and customizations. You move changes around with git and apply database changes with corebos updater.

We still try to keep each module in it's own repository and we try to update them when we find an error but that is done after committing to production.

Finally, answering your questions:

• 2 different perspectives will have 2 different customized cbPerspective extensions. cbPerspective is just a template
• a Perspective repository would consist of the composer.json file that will point to all the repositories and the set of code base patches that are needed

Endless possibilities!

Photo by Ales Krivec on Unsplash