345 were invited to participate in Microsoft’s Logic Apps Live show on YouTube on 5th November 2020. Check out the video below to watch the playback:
Here are the main points covered in the session:
- 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 (https://github.com/Azure/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 (https://github.com/Azure/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 (https://github.com/Azure/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 (https://github.com/Azure/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 (https://github.com/Azure/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
- 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
First podcast of 2020 and Danny’s already forgotten what shirt to wear! In this episode we’re discussing the topic of getting your integration solution migrated
You might think you’d use a migration tool only when your business was ready to move from one tech system to another. So, it’s natural
What a year it’s been! Thinking back to January, we were dealing with the impact of the impending IR35 rule change. As with all software
In this webinar Andrew and Dan take you through the repos (repositories) that make up the open source project and explain what they do.
Here is the low-down of what we cover:
Description of the design intent.
The packages that make up the migrator and how they interact.
How the tool could be extended.
Where you’re likely to be making contributions to the Migrator.
We show you the repos in GitHub.
Demonstration of how to debug the Migrator in Visual Studio.