Leading up to this point, you have been expanding the mapping in Studio and the generated manual code in Visual Studio to include the Business Object Card and related items, such as Valuesets, Constants rules and Bags. You now have two brand new engines built, ready and rearing to go. The next step is to get them deployed and loaded in the runtime environment and setup the Portal Operations and Runtime so it gains knowledge of all the new stuff.


In most real-life production setups, the runtime environment includes a master server and one or more migration servers. The master server serves as a repository for common files as well as common master databases of the runtime environment. A migration server is a (normally quite powerful) server used to execute the actual migration. In addition, the Studio and Visual Studio will be running on the individual Workstation of each team member.


This training setup is of course simpler - everything runs on the same machine. 



DeployDeploy is done using the migFx extension in Visual Studio. The engine is built (compiled) and the resulting libraries are copied to a shared folder on on the master server  
Copy & LoadOn the migration server, the runtime must be stopped and restarted, as the running instance has the old version of the engine libraries loaded.
  • When starting, the runtime copies the engine libraries from the shared location on the master server to a local location on the migration server itself
  • Once copied, the new engine libraries are loaded into the running Runtime
SetupOnce the new engine libraries are loaded in the Runtime, the engine and the runtime must be synchronized.
  • Staging tables must be created/modified in the Staging database for Source System metadata structures, Valuesets and Views
  • Stored procedures in the Staging database to support the export of the Business Objects must be create


  •  obsolete Business Objects, Source System metadata structures, Valuesets, Views and Runtime Constants must be created/modified in the Migration database
Of course, it is crucial that the runtime databases and the generated code in the engine correspond. But don't worry, the engine will always refuse to do anything at all if the two do not match up.


Apart from the first initial step of deploying the engines, you will now leave Visual Studio behind and proceed to the next component in migFx: The Portal Operations. The Portal Operations is part of the browser-based Portal. You will use the Portal Operations to control and manage the execution of migration jobs in the Runtime running on the migration server.


A quick note before you start: From now on, we assume that the preceding exercises in Studio were completed correctly. If at any point you realize that you need to go back to a previous exercise to correct something in Studio, please remember the complete path any correction in Studio needs to go through in order to be operational in the Portal Operations.

  1. Studio
    1. Validate without any validation errors
    2. Publish to Generator
  2. Visual Studio
    1. Generate Engine
    2. Deploy Engine, verify that deployment succeeds
  3. Portal Operations
    1. Restart Track
    2. Run Setup of relevant Engine 
    3. Check that Setup job completes successfully 

You must go through these steps every time you have modified in Studio in order to test your changes in the Portal Operation!


Deploy

Deploy to build the engine and deploy it to the shared folder on the master server.

  • Right-click the class library project in Visual Studio and select MigFx: Deploy in the context menu (for the Source engine right-click the SourceEngineCustom project)

  • The migFx Visual Studio will show a dialog listing all the tracks where this engine is deployed and lets you optionally restart the track and run the setup after deployment. In this training setup, the engine is only deployed to one track there is only one.

    At this point, you can actually restart the track to load the new engine and also to run the subsequent setup job. However, for this exercise you will do that a bit later on, so for now just uncheck the Start/Restart Track checkbox and click the Deploy button

    Don't worry if there is a red dot next to the Track. That just means the Track is not currently running.
     



  • The migFx extension will now build the engine and deploy it to the master server
     

  • Remember to Deploy both the Source- and the Target Engine


That's it, you have now deployed your two new engines to the Runtime environment. Now is the time to leave Visual Studio behind and jump to the Portal Operations to start using the engines.



Portal


In order to access the Portal you must open it from a web browser.  

  • Locate and open Microsoft Edge (alternatively  Google Chrome)
  • We have set up Edge with the Portal as your homepage, so it should show up automatically when you launch it. If not, you can navigate to this url: https://localhost:430XX, where XX is your Trainee number - 2 digits (for instance https://localhost:43001 for trainee 01)


For more information look at Exercise 0.2 - Setup Workshop Environment


In the Portal, click the arrow to list the active Projects and then click the Workshop card:



This will get you to the point where you can work on the Workshop project. 



The Portal Structure

The Portal is a web application and is viewed through a web browser, it is important to define the structure of the Portal and the differences between the Portal Operations, Portal State or the Portal itself.


  1. When we mention the Portal we are referring to the Portal as a whole, Portal State is illustrated by box 1. Portal State is where you go to process the results of the migration and to analyze issues etc. More on Portal State in later exercises
  2. The Portal Operations is what the visual Studio deploys into. This is illustrated below by box 2



It is important to keep this in mind when going through these exercises.

For further information on the different sections within the Portal, please follow the links below.

  1. Inductions
  2. Home
  3. Projects
  4. State
  5. Operations
  6. Planning


Action Context Menu and Refresh

In general, you will find the actions you can take in the Portal Operations in 2 locations: The Row Context Menu and the Action Context Menu. 


The Row Context Menu is visible as 3 dots when you hover the cursor of an item in a list:



The Action Context Menu is also 3 dots, but is located in the upper right hand corner of most Portal Operations panels:



Refresh is not automatic 


In most of the panels in the Client Area of the Portal Operations, you will see this Refresh button in the upper right corner.

Using Portal Operations, you are really working in a client application sending instructions to the Runtime running on a server. In this simplified training setup, the Runtime is executing on the same machine you are using. But in a real-life scenario, the Runtime will typically execute on a different server.


The Portal Operations is communicating with the Runtime via requests to and responses from a backend API, and due to this fact some of the panels in the Portal Operations do not update automatically. You have to click the Refresh button yourself to get the latest news from the Runtime.


So, remember, if you again are scratching your head because some panel in the Portal Operations does not show what you expect: Click the Refresh button before you do anything else.


Interface


The Portal Operations is only a section of the overall portal, for this training, we will only be focusing on Portal Operations.

To read more on the Tracking side of the Portal, please follow the link below:


Exercise 5.1 - Portal, Introduction and Publish


Take a little moment to familiarize yourself with the Portal Operations interface section. It is quite simple.




1 - IndicatorThe (green dot) next to the MigFx - Track 1 shows that the Track is running, when it has stopped this is indicated by a (red dot).
  • The track is the migFx runtime as described in the introduction to this exercise. When it is running (green), it has loaded your engines and is ready to execute whatever you ask it to do
2 - MenuThe Portal Operations menu is presented as a tree view. Simply click any node in the tree view to select that menu item
3 - Client areaThe selection area will always show exactly what you have selected in the menu and are currently looking at



Start (or restart) the track

If the track is stopped (red dot) you need to start it and if it is already running (green dot), you need to restart it in order to copy and load your new engines.

  • Click the Action Context Menu and select Restart 


The track is now started, has loaded your new engines (provided of course, that you have deployed the engines in the previous step) and is idling, ready to execute your wishes!


Setup Engines

Next step is to run 2 setup jobs to setup the Source-and Target engines in order to synchronize the engines and the runtime

  • In the menu, select Administration/Manage
  • Check these radio buttons
    • Source Engine: Setup only
    • Target Engine: Setup
    • Leave all other on Skip


  •  Click the Action Context Menu and select Submit

  • The Portal Operations will now show a dialog previewing the changes in the runtime. In this case the changes are 

    • for the Source engine

      • The new Source metadata structure Src.DebitCard

      • The new View CardStatus

      • The new Business Entity Card

    • for the DataServices

      • Valueset TranslateCardTypes from the Source engine

      • Valuesets CardTypes and CardStatus from the Target Engine

      • Initially, the tabs in the dialog are marked with a red dot. This is to warn you of potential data loss

      • You need to click the Accept button on both the Source preview tab and the DataServices preview tab in order to enable the Ok button

  • Click Ok and the Portal Operations will submit two jobs, one for each engine


TIP: These last 2 steps of restarting the Track and running setup of the newly deployed engines can be launched directly when deploying the engine from Visual Studio. Just check the Start/Restart Track checkbox and the Run setup checkbox in the Deploy dialog.



Check jobs

In the Portal Operations job list you can follow the execution of the 2 jobs and check that they were completed successfully

  • In the Portal Operations menu, select Execution/Jobs
  • The 2 newest jobs are at the top of the list
  • In the 2 panels to the right of the job list, you can see
    • The parameters for the job
    • The results of the job execution
  • Right click on the row of the new job to see the Instances option, this will show the job log. If a job fails, this is the place to look for an explanation
  • Please note that this panel refreshes automatically, so there is no Refresh Button



What happened here?

You have built and deployed the Source- and Target engines to the Portal Operations and runtime environment. By restarting the track, you cause the track to load the new engines and finally by running the 2 setup jobs you have synchronized the engines and the runtime so the latter now knows about the new items you have added in Studio.


If you look at the Business Objects to Export (select Source/Objects in the Portal Operations menu and click the Refresh button, you will see that the new Card Business Object is now present, but that nothing has been exported yet.



Card is marked red because it is depending on data from the Source System for Src.DebitCard and also the view CardStatus, both of which have not been loaded yet. So it would not make any sense to export the Cards before loading these.


Luckily that's exactly what you are going to do in the next exercise.