Proof of Migration tool

From our customers and our own experience, we know that there is a strong need to minimize testing costs in the migration phase. That is why WeAreFrank! has built the open-source Proof of Migration (POM) tool. This tool takes automated work off your hands during the migration from BW5 (or any other integration framework) to the Frank!Framework.

How does the Proof of Migration Tool work?

WeAreFrank! places a new migrated integration component for your existing integration component in the chain. In addition to the migrated functionality, the new integration component contains three other components, namely the Frank!Proxy, the Frank!ShadowSender and the Frank!Compare.

Component 1 Proxy

During the first phase, the newly placed component passes the original request and the original reply to the calling system. So nothing has changed for the calling system.

Component 2 ShadowSender

The ShadowSender offers a copy of the input message in parallel to the Frank!Adapter. The original input message and the reply in the Frank!Adapter are saved for use in the Frank!Compare.

Component 3 the new Frank!Configuration

The migrated component, the Frank!Configuration, which may or may not have been automatically generated with our Frank!Generator, will process the same request with the underlying landscape in parallel with the proxy and will compare the received reply with the last component.

Component 4 Comparison

This component compares the parallel-generated reply with the reply of the old integration component. If the reply differs, there is a potential defect and the complete information will be stored. The storage can be realized on a file system or in a database.

Result of the Proof of Migration Tool

The Proof of Migration Tool is also very useful in the test and acceptance environments, because the tester only has to provide messages and the results are checked automatically. But the ultimate goal of the tooling is the Proof of Migration! In the case of dissimilar messages, our Proof of Migration Tool signals that a potential defect has been found in the new Frank!Configuration and it can be adjusted and easily deployed. The messages from the production environment can be made anonymous and used directly as a unit test. In practice, most errors will already be found in an earlier phase of testing or acceptance. In the production environment, only a proof of migration would need to take place.

The Proof of Migration Tool greatly simplifies and minimizes the work of the testers.

How can the Proof of Migration Tool be placed between the existing migration component and the consumer of the service?

The solution depends on your situation and the communication protocol. If the http protocol is used, the most obvious option is to make an endpoint adjustment in the load balancer or api-gateway. If your organization uses queueing, it is in most cases most convenient to adjust the component to be migrated.

Can the Proof of Migration Tool be used in combination with update-and-create patterns?

Yes. The Proof of Migration Tool, as explained, focuses on so-called “Retrieval Services”, but it is also possible to use the Proof of Migration Tool for update-and-create patterns. The proxy mechanism is then not only applied to the incoming connection but also to the relevant outgoing connections. The Frank!Compare then compares all outgoing messages and, of course, does not call the backend system a second time.

In which situations is the Proof of Migration Tool not useful?

In file-based patterns proof of migration is difficult to apply. We would like to investigate your situation to see what the possibilities are.

How do I use the Proof of Migration Tool in the non-production environments?

Proof of migration is a term associated with your production environment, but your entire DTAP will benefit from the components that together form the Proof of Migration Tool.

In the test environment, the tester performs his tests and does not have to make a comparison with his test expectation. The performed tests can also be captured in the test/debug tooling and used as an automated test.

In the acceptance environment, the test effort of the business testers will be minimized.

Can the Proof of Migration Tool also shadow run the old component?

Yes, in the Proof of Migration situation you also have the choice to use the migrated component as the guide. In that case, the outcome of the “old” migration component is used as validation.

What is a difference for the Frank!Compare? Isn't everything different if there is a timestamp in it, for example?

There are always data, such as timestamps, that are not relevant for a comparison. In the tooling these can be marked so that no false errors are reported.

What does the Proof of Migration Tool cost?

The components used in the Proof of Migration Tool are open-source and part of our open-source framework! We use our framework as a toolkit when we work for our customers.

Q&A about the Proof of Migration Tool