Thursday, November 26, 2020

Document Your Business and Technical Processes with MkDocs

If you thought documenting your business processes and application code was too hard or tools were too expensive, you should check out the FREE Python based MKDocs offering.

What a great way to start documenting all your company's common business knowledge in one place.

MkDocs is an open source Python static site generator for creating documentation using simple Markdown based text documents. Simply edit your MarkDown content files and they are available to anyone in the company who has access to the site.

No database required.

This is a quick way to establish one or more departmental knowledgebases with shareable business and system process documentation.

An MkDocs project directory structure could also be turned into a git project if desired so the entire site would be versioned in a git repository.

I created a quick getting started guide for IBM i, but MkDocs works on any platform.

Monday, September 02, 2019

Windows 10, SSH and VS Code - Nice !!

As I start to use SSH more and more to access remote IBM i and Linux systems and also use VS Code and other editors with IBM i and Linux I am always looking for ways to make life easier when accessing a remote system and running commands. Ideally I like to work from one user interface if possible.

Unfortunately VS Code doesn't have a built-in SSH client or terminal. In my case I typically use putty or MobaXterm as my go to SSH client in Windows 10. 

As I started experimenting more with VS Code I found out that Code can work with add-ins like SSH FS to access remote file systems and edit directly. This is invaluable for editing files from a remote system. 

However to run bash commands or IBM i system commands on a remote system still required putty or MobaXterm, until I found out that I can use open ssh from the command line terminal in VS Code. And I also found that Windows 10 now has a built-in SSH client and server which means I can initiate a remote SSH session from the Command Prompt or from the VS Code terminal Window. 

This means when I am working remotely with an IBM i or Linux system I can now connect to an SSH file system with SSH FS and I can also issue commands in a terminal session as well. Too bad there's not a 5250 interface for VS Code.

Have fun with this and check out the following article link on using ssh in Windows

Also check out this article on setting up to use VS Code with IBM i.

And remember that it's now easier than ever to use SSH with Windows 10. 

Monday, April 15, 2019

QUSER Session Recording - Mono on IBM i - The Port to AIX and IBM i

QUSER Session Recording - Mono on IBM i - The Port to AIX and IBM i

Check out this video of Calvin Buckley's session and learn how Mono was ported to run .Net natively on IBM i

Sunday, March 17, 2019

Interesting List of Queueing Apps

There are many queueing systems out there. Each one of them is different and was created for solving certain problems. This page tries to collect the libraries that are widely popular and have a successful record of running on (big) production systems.

Wednesday, March 13, 2019

Building Out The .NET Stack Around Mono for IBM i

Check out this article from IT Jungle on building out the .Net stack around Mono on IBM i. My favorite development platform is growing legs on IBM i.

Wednesday, August 22, 2018

Friday, August 03, 2018

Creating scalable RPA processes with Queueing

Often when I am talking with customers and prospects they ask about the concept of queueing transactions and then level loading across multiple agents/servers/bots so that their workloads are instantly scalable up or down as needed by adding additional agents into the mix.

Here's an example where queueing might be useful: Let's say a company needs to interact with a vendor or customer web site, an SAP application or some other UI based ERP or business application that can only process one transaction at a time. Often a single bot won't cut it because it's not fast enough because of application or other response time issues, so you need something that is infinitely scalable. Also a server in many cases is limited to one transaction at a time because it's automating using a user interface. Background processes are another story because a single server/agent/bot can handle many background process threads simultaneously.

By intercepting all transactions as they come in and funneling them to a single queue or inbox, one or more (pick a number) robotic processes can pick up the next transaction as it finishes the previous one. Think of it as being similar to picking up the next phone call in a call center or being next in line at the grocery store. First-in, first out using as many lines available.

So how does this queueing thing work ? Well the idea is that as a transaction comes in and gets added to a database or some other data store, a queue entry is written immediately so the next agent/process/bot can pick up the transaction and get it done. As the next sequential entry gets picked up it gets removed from the queue or marked as in-process or complete.

You might consider using a message queue system such as Microsoft Message Queue (MSMQ), WebSphereMQ, RabbitMQ, ActiveMQ or even a platform such as Apache Kafka. There are probably others that I missed. These queueing systems can be implemented simply and used with any RPA tool set that can call an API or web service. However they do add another layer to the complexity and overhead of your RPA process by adding another moving part for your application or RPA process to monitor: The message queue service.

Another simpler option perhaps might be to write queue entries to a database so that they can be processed easily and also the queue can be visualized via an SQL query as needed for reporting purposes. If you have read articles on table queueing theory on the web, there are lots of things written that recommend not using databases as queue mechanisms. I have researched a lot and found that SQL Server (and probably other databases as well) can work nicely as a queueing system if you're careful. The trick is when reading an entry, how do you make sure you process a particular database queue entry only one time ?

While researching on SQL Server methods for locking I learned about the READPAST and UPDLOCK flags. I won't regurgitate other articles so you can simply google the highlighted keywords for yourself and draw your own conclusions. However the upshot is that when these two flags are used on a query combination that reads and updates/deletes a record all in a single transaction, you should be able insure that each queue table entry is handled correctly and only once. When writing a new entry to a queue table you simply perform a standard record insert, so feeding the queue a bunch of transaction data that needs to get processed is very simple.

Hopefully you'll find this technique to be helpful when you're scaling your RPA, Workflow other process automation workloads. This technique should work with any automation toolset or custom process you create where queueing is required.

Sunday, June 24, 2018

Check out Open Source WinAppDriver UI Recorder

A new open-sourced tool is now available for the Windows Application Driver (WinAppDriver) community: the WinAppDriver UI Recorder tool. This tool will enable users to easily create automated UI tests.
For those of you not familiar with WinAppDriver, it is a UI automation service for Windows 10 that users can use to test their applications.