8 minute read

Part 9: I no longer hear ā€œWho send these test mails?ā€

LinkedIn Post Part 9

Carousel: I no longer hear ā€˜Who send these test mails?ā€™

I once was lucky to work for a customer who had complete dedicated development and test environments. By complete I mean, that each employee had a development and test user account and mailbox. I never had such a luxury again. I can vividly remember the times when I accidently send a mail to the upper management when implementing and testing an application in the past.

Even more unprofessional is it when you send mail to external recipients. Luckily this is no longer an issue. With WEBCON BPS you have a few options to test the mail layout without going through the process and prevent situations like above:

  • Preview the mails before using the existing data
  • Even in different languages
    Preview mails in different languages
    Preview mails in different languages
  • Send a test mail to any account without going through a process
    Send a test mail
    Send a test mail
    Check the send test mail
    Check the send test mail
  • Redirecting the outgoing mails for a process to a specific account
  • Redirecting the outgoing mails of all process for the whole environment
    Redirect all mails while testing
    Redirect all mails while testing
    Check recipients of redirected mails
    Check recipients of redirected mails

Iā€™ve already stated it but WEBCON designed WEBCON BPS in a way which delights my developer heart.

At this point in time my series I Ā­šŸ’— WEBCON BPS consist of nine posts. Four out of these have been about testing? Yes and Iā€™m not sorry for not sticking to ā€˜All good things come in threesā€™. :) After all testing, debugging, deploying solutions easily and fast will increase the user satisfaction. Not only those of the end users but those who actually develop/implement solutions.

Part 10: Yes, remove this ā€¦ AARRRGH (Dependency tracking)

LinkedIn Post Part 10

Carousel: Yes, remove this ā€¦ AARRRGH (Dependency tracking)

Did you ever encounter a situation, where the business had a requirement, which has a major impact on the behavior of a process. A few weeks later it was no longer necessary. For example, a claims process can be marked as critical, which will:

  • require additional fields to be filled out,
  • Send mails to the management
  • Create documents
  • Change the flow of the workflow

Would you be willing to remove this central logic? With pro-code you have static code analysis, unit tests and so on. Back in the past I would have just removed the elements from the source code, and, if it builds, everything is fine. What do you in a low-code environment though?

I rely on the dependency tracking of WEBCON BPS. It will show me where something is used, and I can change the occurrences. Examples of the places:

  • Actions
  • Data connections
  • Data sources
  • Fields
  • Custom functions
  • UI elements like views

The dependency tracking works not only inside a process but across all applications.

In which applications is artifact x?
In which applications is artifact x?

For example, the Audit management could create a workflow in the Incident management and set a field. This field would than have a reference to the action in the Audit management. It will also prevent deleting specific artifacts like a workflow step if this step was already used in a workflow instance. This is necessary to ensure data integrity of the workflow history, which is required for the auditability.

Deletion is prevented, if a step was used.
Deletion is prevented, if a step was used.

This works really well and ensures a higher satisfaction. I trust this enough that I removed something central from a process one day before I went on vacation. Also, the customer was going into a test phase.

Part 11: From OnPrem to SaaS and back? Without migration effort? šŸ¤£

LinkedIn Post Part 11

From OnPrem to SaaS and back? Without migration effort? šŸ¤£
From OnPrem to SaaS and back? Without migration effort? šŸ¤£

What do I mean with ā€˜processes donā€™t careā€™? Do you have long running processes, with reminders or so? They will just work as normal.

But back to the start. First of all, why would you want this option all?

  • You want to validate the platform with minor investments. If this it holds up to the promises you want to have the platform under your control.
  • You start on an old server and at the end of itā€™s live thereā€™s the question how you want to continue.
  • Due to regulations one of your subsidiaries in a country can no longer use the public SaaS environment.
  • A subsidiary getā€™s sold and they need to keep there data.
  • Changes in the costs structure

I canā€™t tell whether these are unlikely reasons, but I know that this works. You can even have an OnPrem development environment and run the test and production environment in the cloud, as you can simply transport the processes. This shows, that WEBCON is dedicated to ensure your investments in terms of time and effort to digitize your processes, whatever option you may consider.

This is how the process would look like:

OnPrem -> SaaS

  • Backup and provide your SQL databases.
  • Change the DNS so that the URL would point to the correct IP address.

SaaS -> OnPrem

  • Install the server.
  • Request the SQL databases and restore the backups.
  • Change the DNS so that the URL would point to the new server.

Your processes will continue and thereā€™s no need to touch them. I donā€™t know whether thereā€™s any other platform which offers you this flexibility. I hope no persons reads this, who needed to migration SharePoint Nintex workflows. ;)

Of course, the above would be more complex if you have:

  • An unsupported authentication method in the other environment.
  • If the user names (UPN) would differ, you may need to migrate them.
  • You are consuming data from a source which cannot be reached from the target environment.

I will dive into the last issue with the twelfth post in my series I šŸ’— WEBCON BPS. You will see that this wonā€™t be a problem at all. :)

Part 12: Same process, multiple subsidiaries but different data sources?

Those requests are a piece of cake for WEBCON. LinkedIn Post Part 12

After lots of back and forth, the business has finally agreed on a process which can be used across all subsidiaries. After this success has sunken in, the next step is to define the data. At this point you realize you need customer data and:

  • Two subsidiaries use a common BC environment but are different companies.
  • Another subsidiary use still and outdated Navision version which doesnā€™t offer REST or even SOAP APIs to access the data.
  • You heard a rumor that another company will be bought, it will take time to integrate it into your environment but the new process should be used their too.

Before I encountered WEBCON BPS I would have started cursing. How should one be able to use the same process definition to read customer data from different sources? Not only is the data itself different, but also the way the data is available.

Iā€™m glad that WEBCON already encountered this issue and implemented a really smart way to handle this. I donā€™t have to care about it at all.

  • Each subsidiary will be represented as a ā€œbusiness entityā€, if you know Navision/BC you can use the term ā€˜Companyā€™.
  • Each business entity will have their own workflow instances (data) secured by an own set of privileges. Itā€™s really similar to a ā€˜Companyā€™.
  • You define a general data source. For example with the customer data Number and Name. This will be the default one.
  • Depending on this you can define child data sources for each business entity (subsidiary) and these can refer to completely different types of data sources. These could be MSSQL databases, oracle, REST, SOAP, SharePoint lists and even custom ones.

Each workflow instance is created in the context of such a business entity and whenever the customer data source is used WEBCON BPS will fetch the data from the correct data source. I donā€™t have to do anything about it. This really delights my developer heart. Even more so as I started my professional career as NAV developer, which is also the reason why I used these examples. :)

I ended the eleventh post of my series I šŸ’— WEBCON BPS From OnPrem to SaaS and back? Without migration effort? šŸ¤£ with the problem: You are consuming data from a source which cannot be reached from the target environment.

The solution for this is obviously fairly easy. If you migrated the data and the primary keys stayed the same, you only need to change the connection.

In case you think, this is just one building block in ā€œone process to rule them allā€ and it wonā€™t work in a real world example check out:

..of the most critical business processes .. to unify it across 27 countriesā€¦ Success story by PWC CEE

Series

Part Title Blog LinkedIn
01 99% Low-code/no-code implementation 1% high code Blog LinkedIn
02 Leveraging benefits aka early go-live in < 2 month Blog LinkedIn
03 Transporting applications Dev->Test->Prod Blog LinkedIn
04 Change request thereā€™s a typo Blog LinkedIn
05 Greatly reduced testing time Blog LinkedIn
06 Time to market Blog LinkedIn
07 Gather debugging information Blog LinkedIn
08 Being CEO for a day (working on behalf) Blog LinkedIn
09 I no longer hear ā€œWho send these test mails?ā€ Blog LinkedIn
10 Yes, remove this ā€¦ AARRRGH (Dependency tracking) Blog LinkedIn
11 From OnPrem to SaaS and back? Without migration effort? šŸ¤£ Blog LinkedIn
12 Same process, multiple subsidiaries but different data sources? Blog LinkedIn
13 Ever evolving Blog LinkedIn
14 Multilanguage and evergreen documentation Blog LinkedIn
15 If you repeat yourself, you are doing it wrong Blog LinkedIn
16 In numbers I trust Blog LinkedIn

Comments