 Hello all. Thank you for attending this session. The name of the session is blockchain hyperledger all in one. Fabric self, fabric explorer have to change code and monitor. The presentation slides are in English and the presenter will speak in Portuguese. You may use the live session translation from link below the description of this session. Your questions can be written in English or Portuguese and the presenter will answer then at the end of this session. My name is Magnófico Valkante. I am from the city of Rio de Janeiro, Brazil. I am speaking in Portuguese. If you want you can use the translation also from Portuguese to English. I am trained in electrical engineering with systems in computing, I have MBI in management of projects and I have mastered in science and in science of computing with focus in cryptography and blockchain. I am Java Champion, leader of the group of Java users of Rio de Janeiro. I am PMP and certified in Togaf9. I am also certified by the Blockchain Training Alliance in Blockchain Business Foundations and I am member of the hyperledger chapter Brazil. About this presentation, we will talk a little about the scenario of the built-in blockchain example, the initial configuration of the Fabric CA setup, the configuration of the Fabric, the configuration of the Haft Orders, the configuration of the monitoring components, some tips to check the execution of the TenCode, the deployment status of the TenCode, the execution of transactions, the configuration of the Hyperledger Explorer. Let's take a look at how the Explorer makes the vision and exhibits the blocks and I will talk about some challenges in the production environment. In the end, we will have the answers to the questions of the audience. What is the scenario of the blockchain network? Two organizations, the Coff and the Juice organization, decided to create a blockchain network to be able to negotiate and deal with natural juices and related things related to natural drinks, with views on the regulation of tracking from point to point. These two companies, the Coff and the Juice, decided to create another company called Trading Company. The Trading Company is responsible for managing business networks to support growth with other partners. In the future, it will be able to enter the Wine Company. The Wine Company is like an example available for those who are working and lowering the source code that is available in the GitHub. The blockchain network aims to support tracking of all the productive chain of juices, drinks, etc. How is the blockchain network designed? We have some organizations, the Coff and the Juice organization, the Trading Organization. The Coff and the Juice organization agreed on this and created a third organization called Trading to manage the blockchain network. This Trading Organization created another organization called Explorer to facilitate the network visualization. The TLS Ring organization serves only to be able to provide the TLS certification of the blockchain network. In the future, whoever lowers the source code and wants to work on their own, doing the exercise of this scenario of a blockchain network, can add the Wine network resources. You can specialise the source code, the fundamental components, from the examples that are available in the GitHub. I left a QR code for everyone. From this QR code, you can use your smartphone to access the examples or you can type this link directly, or even using the presentation slides, enter the link directly and download all the components. All the presentation material, all the instructions are all in the GitHub repository that I am informing here in this presentation. The configuration of the TLS Ring is the first configuration to be made. On the left side, there is an image. This image shows the configuration of the TLS Ring fabrication. In this instance, in this configuration step, we have the creation of four hostages of the TLS Ring, four servers of the TLS Ring, one for Trading, Company, one for Coff, Company and the other for Deuce, Company. These are four factory-made servers. This one on the left side of the configuration. As I said, all the instructions are there in the GitHub repository, how to configure them. But I draw your attention to two items in configuration time. One of the items that I suggest the change is related to the expectation of the certificate. The standard amount is 8,760 hours. I have, in practice, changed this standard amount to some other different value, so as not to be alone in that standard period, some other value that interests me. And the other thing that you should change in the configuration files in Febric Clash Configure, Feb-CA-Serve Configure, is the configuration of the address of the organization, of where it is, how it identifies, etc., and especially the hostages. Relate the hostages to the configuration files so that when you run the examples and run them in production, you have a total completeness, a total mapping of how your Febric-CA is configured. The next configuration of Febric Clash was a configuration that many of you already know, this configuration that is shown here is the configuration for the docker. I draw your attention to two configuration blocks. The first configuration block is the environment variable corp.local.msp.id, and the variable corp.msp.config.path. These variables are pointing to the organization, how you set up your organization. And below we have the certificate configurations. Note that the certificates that are marked below are already certified by the certificate authority. The next configuration of the Haptioders. The Haptioders have their own configuration file that is related to the digital certificate. So there is the digital customer certificate, the digital server certificate. I call the attention of this configuration here that it appears in the configuration file in the config.txt.yml. So it is important in the configuration of the Haptioders to pay attention to these certificates that you worked and brought from Febric-CA from your organization so that everything works properly. Once again, all this source code is available in the GitHub repository and can be accessed laterally by people. The next configuration is still extending a little, but related to the order.yml file, the configuration of each order. So in the previous slide, we made the configuration in relation to the Genesis block, the transaction blocks, and here the computer itself. So I mark on these slides two important things. One thing is the location of the directory, of the file ledger, the environment order, file ledger, the location. And the location is two of the digital certificates. All the digital certificates have to be related inside of your configuration so that they work properly. The type of Genesis Profile and another important thing is the file ledger prefix. Monitoring components. It is important in your environment, especially in the production environment, to enable the monitoring of your environment so that you can keep it as much as possible and avoid unexpected errors. Some variables of the environment exist in the configuration of each component of the blockchain network so that it can prove this monitoring. In order, the variables of the environment that correspond to the monitoring are these that are on the screen for you. The PIR are also these two that are on the screen for you and the FebriXA are also these two that are on the screen for you. It is important to note that the list always works on a door and this door has to be open in your environment so that the monitoring rule collector can get the information and process them. The variable environment CoreMetricsProvider here in the example was configured with the Prometheus parameter and this is related to a type of monitoring, but there may be other types of monitoring. I suggest you consult the FebriX documentation. Within the example, we created a small monitoring script that serves as a reference for you to be able to use in your production environment. So, using the scripts best to monitor the stability of the environment is very important. This script is an example in which you can keep the information of each one and just change the parameters of the variables of the environment that you will be able to get the information of your environment. Anyone who lowers the source code and executes in your own environment will be able to execute these scripts and will be successful in the collection of the information about health check, health z, log information and metric information, which I think is important for monitoring the environment. Continuity, I created a script, a basic JavaScript application, a simple JavaScript file that makes the verification of access to the network. This JavaScript file opens a connection to the PIA and does some test of connectivity to the blockchain network, without, however, executing transactions. So, creating a script that verifies your connection profile is always very important for you to be able to test your blockchain network infrastructure with the FebriX hyperled that is working adequately as it was designed. This script does not need to investigate the whole network, it can investigate its network portion, in the case of the Juice network, the Juice organization network. Some tips for verification of TIN codes. It is important for you to use the list of TIN codes, the pure TIN code list, to verify which TIN codes are installed, you can put this command, pure TIN code list, in a script and automate it in your environment. Another very important tip is to use the command pure TIN code query, because this command that executes the query in the PIA, it does the query without making a block drop, without generating a transaction on the network. With this, we maintain the intact blockchain at the same time that we verify the integrity of the TIN code, if the TIN code has gone up or not to the productive environment. In quality production, the extension of a TIN code can take more than 10 minutes. I have already participated in project initiatives that the TIN code took approximately 15 minutes to be loaded in a Kubernetes environment. So, how do we monitor if the TIN code has gone up or not? We monitor the pure TIN code using the stanchator parameter and doing the execution of the command pure TIN code query to verify if it returns the information. The last tip is to specialise the contents of your package.json file to each TIN code and keep the dependencies only necessary. It is very common for developers to put a series of dependencies there that are not necessary in the productive environment. So, when the TIN code code goes to the productive environment, it is very important to verify the Json configuration file, the package.json, to verify if everything is correctly specified. There are only necessary and mandatory dependencies in this file. To verify the status of the TIN code deployment, I have here the example for you of those commands that are also in all the source code that is available in the GitHub. So, these are some examples of how we set up to be able to do the tests and verify them. So, we do the first installation, then the verification of how the blockchain network is and what is the last block. If the TIN code was installed, if it was installed, and a query in this TIN code. The TIN code used in the example network is the TIN code, example 0.2, obtained from the FabExample 1.3. So, here in the slide it is the command to install the TIN code, the command to invoke the TIN code and the query command in the TIN code. Remember the following, install the TIN code, invoke the TIN code, create a new transaction on the blockchain network. The query TIN code command does not create a new transaction on the blockchain network, it only serves to verify the situation of the TIN code in the PIR that attends its organization and that is specified within the parameters of configuration and within the PIR address. It is important to do this to be able to verify how the environment is. Configurations of Hyperlegia Explorer, so the example that is available in the GitHub integrates all the initial resources of the platform, integrates the FabExample 1.3, the Haft, the FabExample itself and also integrates the configuration of Hyperlegia Explorer. The Explorer has two configurations, you have to do the configuration of the database first. This is an initial view of the configuration, just a screenshot, a little piece of the screen of how it is configured. I draw attention to two configurations, the GoPath variable, we already had problems in other cases, the Timezone variable, TZ, which is important to specify the same as the DB for the Explorer and the mapping of a folder, of a folder to transact data to both the Explorer DB and the Explorer APP. This will be used later, so it is sometimes necessary for you to delete all the tracking of your database, stored in the blockchain network and start again. In these cases, you will end up using this area here of data exchange. The Explorer APP configuration, this is a screenshot of the configuration screen of the Explorer APP, I draw attention to the variables of the environment here and for the mapping, you have to change some files, you have to change, write the Explorer config, the file config.json, the configuration of the logs, the connection profile, the SSL certificates and your wallet, your configuration wallet. Remember that it is important to download the certificates from your certified certificate authority, from your FabXA, to be able to execute the Hyperledge Explorer. And the additional configuration of the Hyperledge Explorer, it is related to transporting and mapping those files to the environment variables that will actually configure the Explorer. Note that down here, the GoPath is marked, TamiZone, and there are other variables also marked here. It is important for you to understand how your environment variable is configured, discover localhosts, according to the configuration and your need, from the documentation of the Hyperledge Explorer. Once everything is configured, you can verify and explore the execution of the blocks within the Hyperledge Explorer. So I took some screenshots of the Hyperledge Explorer screens. In this case, you can verify that the mapping is for the three orders, but it is only seen as a PIR, which is the PIR 1. Why the PIR 1? Because we configured it to be the common PIR of the network and leave the PIR still free to make transactions. So a recommendation that I pass on to you in production environments is to always be able to map the PIR 1. The other slides are slides on the network configuration, the PIR 1 again, the orders, how they are configured, the organizations, the PIR 1 is the coffee, and the orders are from the Trading Company. And the other blocks are to highlight the operation of this example, at least here in my environment, you will be able to compare the operation later with the material you have and with the configuration that you implemented in your own environment. The exploit allows you to specify some blocks, see how their configuration is, how they passed, etc. Some challenges in production, the security of your environment always comes in the first place. Always check your Docker images, provide quality, guaranteed quality tests for system integration that are connected to your business partner. It is no use to have a quality test environment if this test environment is not in a blockchain network configured with your business partner. Because a lot of things depend on your business partner. Whenever possible, move your containers to Kubernetes environment so that you can scale the blockchain services, program your containers and the geographical information of the order and PIR services so that you can have a guarantee from the point of view of redundancy in the systems, if a certain site with the services falls, another remote and distributed site geographically will not be affected, what keeps your blockchain network in the air. It is very important to configure the HyperXplorer only for internal use in your organization. Avoid and, whenever possible, block access to the HyperXplorer, because it can be used later for some unauthorized person in your environment. So keep it for internal use. And create a monitoring system to track the performance and health of the blockchain services of your network, using the monitoring configurations provided by each component within the service environment. Each environment has a possibility for you to specify the monitoring metrics, to verify the environment's health, specify these metrics, the entry points in each component so that you can keep this in your monitoring environment. Some references to your environment, some references to the audience's and a review of the agenda during the presentation, which was the scenario of the blockchain network, the configuration of the XCA, the factory, the heft, the monitoring components, some tips from the team code, running the transactions and the configuration of the HyperXplorer. In the presentation content, there is a link to the repository in the GitHub where you can download all the material, it is in progress, the construction of this material, but what is already working there is that you can test it in your own environment. Let's go to the questions from the audience. Guys, if you have any questions, if you have any questions or want to ask something, please, if you have time, you can put the questions on the questions panel. If you have questions, please put in the Q&A panel of the session. Without a doubt, no questions. We are getting back to the Q&A panel, no questions in the Q&A panel. Okay, thank you. My contacts are available at the end of the presentation. My contacts are available at the end of this presentation. Thank you very much. You'll see at the other sessions in the global forum. Thank you.