Is there any way to pass parameters or share data with a scheduled task? I understand that you can pass serializable arguments to a Quartz Job, but this seems not to be available in cfschedule. What are the options to achieve this?
The easiest way to do that is just to have a .cfm file that is called by cfschedule that itself calls the CFC and passes the desired methods.
If you want a more flexible solution, I have a Scheduler.cfc that allows you to have a method called at an frequency that you want and you have even pass arguments for the method call.
http://www.bryantwebconsulting.com/blog/index.cfm/2009/2/26/Schedulercfc-10
It can be gotten here.
https://github.com/sebtools/com.sebtools/
The important thing with it is that you have to have Scheduler instantiated into Application scope and a .cfm that is called by cfschedule that runs:
If you just have one method with arguments that needs to be called frequently, then Scheduler.cfc is overkill over the simple solution, but if this is a general problem that you need to solve more frequently, then it can pay off nicely.
You could pass them on the query string of the URL attribute.
example.com/index.cfm?param1=value1¶m2=param2
If your data is complex you can always serialize it to JSON before and use deserializeJSON on the receiving task.
Related
In Glimmer.js, what is the best way to reset a tracked property to an initial value without using the constructor?
Note: Cannot use the constructor because it is only called once on initial page render and never called again on subsequent page clicks.
There are two parts to this answer, but the common theme between them is that they emphasize switching from an imperative style (explicitly setting values in a lifecycle hook) to a declarative style (using true one-way data flow and/or using decorators to clearly indicate where you’re doing some kind of transformation of local state based on arguments).
Are you sure you need to do that? A lot of times people think they do and they should actually just restructure their data flow. For example, much of the time in Ember Classic, people reached for a pattern of "forking" data using hooks like didInsertElement or didReceiveAttrs. In Glimmer components (whether in Ember Octane or in standalone Glimmer.js), it's idiomatic instead to simply manage your updates in the owner of the data: really doing data-down-actions-up.
Occasionally, it does actually make sense to create local copies of tracked data in a component—for example, when you want to have a clean separation between data coming from your API and the way you handle data in a form (because user interfaces are API boundaries!). In those scenarios, the #localCopy and #trackedReset decorators from tracked-toolbox are great solutions.
#localCopy does roughly what its name suggests. It creates a local copy of data passed in via arguments, which you can change locally via actions, but which also switches back to the argument if the argument value changes.
#trackedReset creates some local state which resets when an argument updates. Unlike #localCopy, the state is not a copy of the argument, it just needs to reset when the argument updates.
With either of these approaches, you end up with a much more “declarative” data flow than in the old Ember Classic approach: “forking” the data is done via decorators (approach 2), and much of the time you don’t end up forking it at all because you just push the changes back up to the owner of the original data (1).
I've got the order microservice that's written as go AWS lambda function.
The main function named order-service bound to API Gateway. It receives several parameters like user_id:int, product_ids:array of int, creates an order with artifacts and returns serialized order with order_id and total price.
This function invokes a function named order-item which creates an order-item and returns them in parallel(per product). These functions invoke product and user functions to retrieve information about user and products by their ids.
Then, the order function invokes another lambda called fee-function which takes just total price and user id and gives back fee price. Of course, it calls some other function like user function and so on. Basically, this is a simple example of how the service works in general. Any function calls some others like user-discount, state taxes etc.
The questions are:
Is it good that order function invokes fee function through Amazon, but it can just import fee handler package and run it inside itself?(However, fee function may be called from outside so it must be deployed as a separate function as well)
Is it good that each function receives just user id and loads the user invoking user function? Perhaps, better to preload it and pass it through everywhere? Something else?
Is it good that one function calls other functions and they call some others and so on? is there any better approach in my situation? Use SNS, Step function, dependency injections/aws layers.
The main reason why I asked is to withstand thousands of RPM and not pay a lot.
Thanks for helping. I appreciate this.
This is exactly what Step Functions was created for. You can invoke a Step Functions state machine from API Gateway, as you would a Lambda.
With Step functions you can:
Invoke the state machine with parameters
Orchestrate the order that Lambda functions are invoked
Use the state to store inputs and outputs from each lambda
Have decision points to take different paths based on the output of a previous function
See the AWS Step Functions Getting Started Guide for a good introduction to the service.
I have a very complex form. I need to get the post parameters from that form in the order they have been submitted. The application is created in ring/compojure.
All the parameters that I can get from ring request are preprocessed (grouped, sorted..)
How do I get the raw parameter list (preferably parsed to key/value vector or some other list)?
Could you provide more information about your project. What HTTP server are you using (http-kit, clj-http, aleph), and what middleware do you have applied in your project?
All parameter based things aren't actually part of the ring spec, but are handled by middleware (see https://github.com/ring-clojure/ring/wiki/Parameters), so it greatly depends on what bits you're currently pulling in.
I'm not aware of any ring middleware that currently exist that do you want, they all seem to parse the parameter list and put it into a hashmap, and if multiple parameters exist with the same key name, they make the value in the hashmap a vector of the items.
That all being said, I have to ask. Why do you need them in a particular order?
Your best option is to create your own middleware. Use the wrap-param middleware as a guide. You just need to do your custom stuff at https://github.com/mmcgrana/ring/blob/master/ring-core/src/ring/middleware/params.clj#L29
That said, I also be wary of expecting the params in a particular order as it will make brittle the client-server communication.
The <cfwddx> tag can easily be used to serialize and deserialize complex data types such as arrays, structs and queries, but not cfc instances.
What's the best way to serialize and later deserialize a cfc?
Because of the nature of a CFC instance (data hiding), the wddx process cannot look "inside" of it in order to serialize it.
However, you do have two options for CFC instance serialization, depending on what you're looking to accomplish.
If you want to serialize the internal state of your CFC instance, you should just add a method within your CFC which returns the variables scope of the CFC instance. You can then simply serialize the response from calling that method. getMemento() or getInstanceData() should work. -- Thanks Scott Stroz!
If you want to serialize the metadata (properties and methods) of the CFC instance, you could use ColdFusion's build in function getComponentMetadata() and serialize the result of that call. -- Thanks Dan Bracuk!
Check out ObjectSave() and ObjectLoad(), but IMO they can be risky if the serialized data is to be loaded in a different version of CF down the road.
I'm using the CreateObject() method to create an instance of a CFC and then interacting with this newly created 'instance'. I'm doing this because that's how it seems to be done, but I don't understand why we do this.
Why can't we just interact with the CFC directly instead of creating an instance of it?
A CFC is just a file with some code in it, so it makes little sense to suggest "interacting" with it, just the same as you might suggest "interacting" with a CFM file without <cfinclude>-ing it or similar.
A CFC defines a component, and to use a component, one creates an instance of it. In some languages - eg Java - one can have static properties and methods, and one can access them via the class rather than necessarily object, but CFML does not have this concept. CFCs define components which are used as objects, just the same as in other languages a class defines what it is to be an object, and to use an object, one first needs to create an instance of it.
You can call the cfc directly using cfinvoke. You just have to realize that cfinvoke creates an object of the cfc first, then executes the method you invoked. Also, once the method is invoked, the object is no longer available.
If your .cfm page is only going to use one method of the component, cfinvoke is ok because there is less code for you to write. However, if you use two or more, it's less efficient because a new object has to be created each time.
In other word, while you don't have to create an instance of the cfc first, it's often a good idea to do so.
I hope you have read OOPs and its practices. CFC is your 'blueprint' (say a car design) and object is your own data model (say a car of blue color (method to set color), with nitrogen filled tires (method to set pressure in tires) and runs on LPG (method for fuel type)). CF allow you interact directly with CFC (CFINVOKE) and you do not have to create an instance each time but it just only make sense that you would not want to go to workshop/design lab each time you want to change a configuration for your car.