I think it's bad idea to try and build an fmeobjects python script to do so.

Create a workspace that reads, transforms and writes out your data. Make sure the input and output are parameters (generally are by default.)

Option 1: no programming required

Create a csv/excel file containing columns for the parameters, and each row corresponds to a job to be run.

"C:\\Program Files\\FME2019\\fme.exe" C:\\FME_workspaces\\myworkspace.fmw --input "111.shp" --output "c:\\output\\222.shp"

@jwma1231 I agree with @jdh - why write python code when you already know the transformer (PointCloudCombiner) you could use in FME Workbench. We would recommend avoiding coding where possible. I think the forum members would be interested to understand why you're inclined to use Python and FME Objects in this way. That might give use some ideas on how we might improve FME Workbench.

Thanks a lot for your comments!

Those two options are exactly the solutions I was looking for!

I think there is much more degree of freedom if it's able to use programming software so that we can integrate other programs (e.g., ArcGIS, FME, QGIS, etc) into one system.

Beyond also agreeing with @markatsafe and @jdh with not using Python when it isn't needed,  the module to call is:

Import fmeobjects

The API classes accessible from this are described here:

https://docs.safe.com/fme/html/FME_Objects_Python_API/index.html

....but, going down a Python/Coding route is always problematic on so many levels from my own programming experience.  It might seem to offer more flexibility:  It does, but on benefit/cost, it always tends to fare the worst if only doing it at a small scale within a single corporate entity, you have to spend SO much time in in-house maintenance and tweaking that you lose time otherwise that could be spent in design and execution of the solution that you are trying to provide.   It is generally far better to use the tools the software/solutions vendors provides out-of-the-box and integrate them at the highest interface level possible rather than getting into writing low-level, granular coding.  It might seem less elegant than a "single custom program that does everything in one piece of Python code Eg. Mixing ArcPy and FMEObjects in one Subroutine", but this can be false economy.  The solution providers like FME are the one that have done the heavy lifting in making sure their installation package works on a myriad of the computer configuration variations you will find or will be deployed witin an organsiation for the life of the solution, that the right supporting runtimes and libraries are deployed properly, and are constantly sinking R&D into their products so that as their software improves, so does your solution.   Whereas your own private code relies on you to put together and maintain your own deployment package, be on call to figure out why it works on your PC but not on others (Python is particularly problematic with this),  document it so that if you aren't on hand someone can make sense of the design of your solution,  change the code for bug fixes etc. you end up spending a lot of time on these aspects.