AIS Transformation: Dive into Microsoft’s Logic Apps Live Recap

In the captivating Logic Apps Live session on YouTube, 345 participants delved into the intricacies of Microsoft’s Logic Apps, focusing on the seamless migration of BizTalk applications to Azure. The event, held on 5th November 2020, offered valuable insights into the design intent and key stages of the Azure Integration Migration process. Led by Rebecca, the discussion highlighted the pluggable model’s core, represented by the aimcore GitHub repository, and emphasized the significance of aimtool, aimmodel, aimbiztalk, and aimazure in the migration journey. Let’s explore the details of each repository and package, shedding light on the future extensibility and diverse applications of this powerful tool.

Here are the main points covered in the session:

Design intent:

  • Convert BizTalk Apps to AIS
  • Be able to support multiple inputs (e.g. BizTalk, other integration techologies such as Tibco, IBM WebSphere, MuleSoft)
  • CLI initially – but support other runners
  • Be able to support multiple flavours of output (LogicApps v1 / v2 / on-prem / perf optimised / low-latency)
  • Be extensible – ability to add more functionality easily


Talk through the design diagram:

  • Last week we had a great explanation from Rebecca about what each stage does, this time we explore how this works from a design perspective
  • Each of the phases of execution we call a stage, and each component that runs under each of these stages we call a stage runner
  • Note that during each stage the tool is reading from and writing to an in-memory object model

What each repo is for:

  • We have your BizTalk app on one side and your new shiny Azure app on the other
  • In the middle is “Azure Integration Migration”
  • Note that this is built up as separate packages that come together to compose a working application
  • The GitHub repos correspond to the packages that make up the tool
  • GitHub repos are prefixed with “aim” –> Azure Integration Migration


The repos and packages:

  • aimcore (
    • This is the core runner for the migration process
    • Each of the stages in the pluggable model is implemented as an interface
    • At runtime the core runner will discover components implementing these interfaces ad build up a collection of them
    • The tool then orders the components in each stage based on their priority (e.g. 10, 20, 30)
    • Then executes each of the stages in turn, executes each stage runner in priority order
  • aimtool (
    • Contains the code for the CLI (i.e. the executable that is run – aim.exe)
    • Is the main repo for documentation and issues
    • Contains all the ReadMe files
  • aimmodel (
    • Contains source and target models
    • Source model: this is overridden by a model in ambiztalk
    • Target model: this is baked into the package
  • aimbiztalk (
    • Contains a BizTalk-specific object model
    • Contains source and config for parsing and converting BizTalk artifacts
    • There is where you would control what is parsed, and what properties are supported
    • There are a series of YAML files that control what Azure artefacts are created
    • Contains test scenarios – BizTalk applications and MSIs that we can convert
  • aimazure (
    • Contains source and templates for generating Azure artifacts
    • Contains ARM templates and liquidised ARM templates and scripts for all created resources
    • This is where you would change the definition for a deployed resource


Future extensibility:

  • That’s the tool as delivered today
  • If you wanted to deliver the tool in another format, maybe as a wizard or a website you could add packages in for this
  • If you wanted to create specific output, for perf or an industry-specific output such as EDI, you would be looking in the templates area (add new package or extend the current one)
  • If you wanted to convert from another integration technology, e.g. IBM WebSphere or MuleSoft, you could create packages to replace aimbiztalk
  • Finally, this tool creates integration apps in AIS. You could create an app modeler that populated the target model and then use the code generation to build a working app in azure

More on this topic…

DevOps at 345 Technology
Peter Marshall

Why 345 embraces DevOps

Collaboration cracks it Here at 345 Technology we believe that the toughest challenges can be solved when highly skilled people work together, trust each other

Read More »

Share this post