AWS Lambda Command Line Automation

As one begins to write more sophisticated AWS Lambda functions, it quickly becomes clear that using shell scripts and the CLI to package, deploy and test will speed up development time. I often start in the AWS Console; then as the code becomes more complex, move to a local editor.

Packaging at the Command Line – OS X

Here’s a helpful script to package up your function. I called mine

rm -f
zip -r * -x *.sh *.txt

The first two lines are optional. clear is just a personal preference.

rm -f will remove any existing The -f, force, means that rm won’t complain if can’t be found.

zip -r will recursively get all files in the current folder and associated subdirectories. -x instructs zip to ignore any .sh or .txt files such as the .sh doing the zipping.

Don’t forget to chmod +x your shell script or it won’t execute!

Deploying at the Command Line – OS X

aws lambda update-function-code \
--function-name YOUR_FUNCTION_NAME_HERE \
--zip-file fileb://

Assuming you have already created your function using the AWS Console, update-function-code is what you’ll need to use do deploy the created above.

Again, chmod +x your shell script.

Test the Deployment at the Command Line – OS X

The following example can also find its way into a shell script.

aws lambda invoke \
--invocation-type RequestResponse \
--function-name YOUR_FUNCTION_NAME_HERE \
--region us-east-1 \
--log-type Tail \
--payload '{"key1":"12", "key2":"value2", "key3":"value3"}' \

In my case, three shell scripts were created, then a master script to call the three individually.

Feature Photo by Dan Freeman on Unsplash

(Looks like a shell, doesn’t it?)


AWS SWF Responsibility Patterns

Note: this is a conceptual, “how does the SWF design pattern work” article, rather than a “how-to”. In fact, implementation does not need to be Amazon specific, although SWF supports the pattern.

A Naive, Simple Code Example

We may write fairly complex algorithms to fulfill the needs of a complex process. One could write a single function that coordinates an activity such as processing an order. Our naive pseudo-code:

function processOrder(var orderInformation) {
    bool customer = verifyCustomerInfo(orderInformation);
    bool inventory = verifyInventory(orderInformation);
    bool payment = verifyCreditCard(orderInformation);
    bool shipment = scheduleShipment(orderInformation);
    bool notification = notify(orderInformation);

Obviously, we would need to evaluate each step and apply logic along the way. Our processOrder function will quickly become fairly complex as we apply decision logic and have many nested “if this then that”.

In this example, Coordination and Decision are intermingled in the same function. As the complexity of possible outcomes increases, so does the code.

SWF Design Pattern

AWS SWF can help with coordination patterns such as the one above by giving certain elements very specific duties to perform, and by having those elements perform highly cohesive responsibilities of Coordination, Decision and Work.

Main elements of SWF:

  • SWF (Coordinator)
  • Decider
  • Activity Workers

Workflow Starter initiates the workflow lifecycle. From there, the remaining three elements perform specific duties in a cyclical pattern of SWF -> Decider -> SWF -> Activity Worker.

A generic pattern looks like this:

  • SWF receives initiation, updates workflow history and schedules a decision task.
  • Decider receives the task, evaluates history and decides the next Activity.
  • SWF receives decision, then schedules an Activity, and waits for the completion of that Activity.
  • The Activity Worker receives the task, executes it and returns to SWF.
  • SWF receives the result, updates workflow history and schedules a decision task.

In the initial naive code example above, the processOrder function appears to have two responsibilities: Coordination and Decision. SWF will allow us to segregate those activities and have highly cohesive responsibilities.

SWF Conceptual Takeaways

  • The cycle occurring n times is: SWF -> Decider -> SWF -> Activity Worker.
  • Workflow History plays an important role and is recorded by SWF.
  • Given Workflow History, we can amend this cyclic pattern in the following way:
    • SWF (log history)
    • Decider
    • SWF (schedule activity)
    • Activity Worker
  • Updating History allows the Decider to decide appropriately.
  • Each element receives. This implies sharing or passing of data/state.
  • SWF itself, is a coordinator, and will NOT perform the work itself. It either calls the Decider or an Activity Worker.
  • Activity Workers perform work.
  • An Activity Worker is called by and returns results to SWF.
  • Deciders decide which Activity is next, but the Decider does NOT call an Activity Worker directly.
  • Deciders review history, evaluate it and decide the next Activity.
  • The Decider can close a Workflow.



BizTalk Receive Location Server Query

Given a fileserver change, I needed a way to get all the server names for Receive Locations in the BizTalkMgmtDb. The InboundTransportURL would be in the form of \\servername\somepath. This query assumes a valid charindex value — often a dangerous assumption. This did the trick nicely!


  [id], [name], [ActiveStartDT], [InboundTransportURL], replace(left([InboundTransportURL], charindex('\', [InboundTransportURL], 3)), '\', '')


  adm_ReceiveLocation rl (nolock) 


  inboundtransporturl like '%\\%'

order by

  replace(left([InboundTransportURL], charindex('\', [InboundTransportURL], 3)), '\', '')