 Okay, so welcome to this Hyperledger Sweden Meetup. My name is Roland and I'm happy to be your guest for today. And I think today we will have a really great session. And this session is, so that's me. And this session is about chain code development environment. And this is a comparison between the Pinoy and Docker version. So since the new version 2.2, we have the possibility to use the binary version of order API and so on to make an development environment. And this is also the scripted in the documentation. And, but we can use also the old Docker version. And in this talk, I would like to give you an overview about this, both approaches and a small comparison of the process. And then we can make a hands-on tutorial session where I can show you how you can use the binary version or the Docker version. And yeah, here you find our agenda in the slides. Later, I will post the slides on the Meetup page and on the LinkedIn page. And this session is required. You can also watch it later on the Hyperledger Meetup YouTube page. And here I have some collected some links. So here's the link to the GitHub repository, the support material. I have copied this also in the chat. So then you would like to follow this. Then you can look into this repository to see all the steps, what is needed to do this. And then here, two documentation links to Hyperledger favorite documentation, official 2.2 and 2.3, pure chain code depth mode. So it's interesting that in the 2.2 version, you will not find this documentation, this tutorial. And yeah, so it's new. Maybe it will come in the 2.2 version, I don't know. And then here, you will find the medium article, which I have written some links about this topic. Okay, so let's start with a short overview of these both approaches. And so in this session, we are going to talk about chain code development. So in February, we have the possibility to use chain code, the smart contract. And this smart contract can be developed in different languages. And when we see this in a layer, when we order this in a layer, then we can say we have on top this chain code development as an abstract position. And then we can use an favorite contract, the so-called favorite contract API. This is a new one in the 2.2 version. And it's a little bit different to the old Shim version in the 1.4 version. And this is an abstraction layer, which gives you access to the ledger. And it provides an API. And with this API, you can interact with the ledger. So that's an important point to know that you cannot connect directly to the ledger. So you have to use this user API. And then the 2.2 versions, they have a new version of this so-called contract API. And then the old version, there is this call to Shim. With this API, we can connect to this. But it doesn't matter. So this is something, we need something to connect to the ledger. And then we have different possibilities to do that. So the main language, I think the main language to do this is go. And but you can do it also with notaries or Java. And some other languages are in better status. And maybe sometime we will have four or five different languages in which we can write our chain code. And they use then this and contract API implemented in this language. And then we can connect to the ledger. And so this and then we have two possibilities to connect to or to test to write and test our chain code. So there is a so-called binary version. That means that you have, you don't have to use the Docker versions, the Docker version. So you can work without Docker. And on the other side, you have the Docker version. So you can make a Docker network, a Docker compose file. And then you can create a DEF network with one order and one here. And then all with a couch to be database, for example, and so on. So and we have two approaches here. And when we compare these two approaches, the reason, let me first explain why is this important. So the reason is that when you use a chain code in your favorite network, then you have to, especially in the 2.2 version, you have to install it, you have to improve it. And then you have all improves collected, then you can commit to this chain code to the ledger or to the channel. And when you change, when you have a change to this chain code, then you have to upgrade. And then the upgrade process, you have to do the same. So this has a little bit, that comes with a lot of effort. And to keep the way short, we have the possibility to use or to run the beer in a so-called DEF mode. And that's the reason where we call this the DEF mode because we can start the beer in a special mode. And with this mode, we have to start and stop the chain code container or the chain code process by our own. And then we can get rid of this installation and upgrade process. And then it will be very easy to change your chain code, maybe in Go. Today we will see it in Go. And then you can build the chain code and then you have to start the chain code container again and you can test the chain code directly against the beer with a CLI command. And that's the reason why we need, from the developer perspective, a way to do a fast test on our smart contract. And when we compare this, we see that in the binary version, we need a lot of terminal windows. So we can use SSH terminal windows for that, or we can use terminal multiplexer, for example, so that they have one SSH terminal to the machine. And then we have some panels inside of these panels. It's a Schmuck's terminal emulator. And for the binary version, we need four different terminals. And so these are some key effects I have collected to compare this both approaches. So in the binary version, we need one more terminal. And in the Docker edition, we need only three terminals. And so in the binary version, we have a point here, correct environment variables are important. So, and this is an important point to understand when you use Docker and you start the Docker container, then this is an isolated room. So that means that when you use a bot, for example, then you could use the same part on this Docker host again. And because it's isolated in the Docker container, but when you try this in the binary version, when you run now some peer, then you have to take care on this because on this machine can only be one part used. And when you use it in a double, then you will run it in traverse. And the second part is that when you use the binary edition is to know where is your data stored. So, and this is a question where we take not so much effort in this because when we use the Docker version, so we mount the Docker volume in the container. And then we have a data folder on the Docker host, for example, or we create the Docker volume. And then this Docker volume, we have our persistent data, this bar Docker, bar hyperlature production folder. And then you will find it very easily because you have a Docker volume. And when you use the binary version, then it's stored the persistent, the chain code data, the blockchain data is stored on the same place, but on your local physical machine. So, and that's the reason why you have to know where is the data exactly stored in the Docker system or in the favorite system. And then, so you will find it. And to get rid of this, we have to manipulate, we have to use the correct environment variables so that we can place the blockchain data and all other variables which we could need to create a binary development version which will run on this machine. And one important point is that we have an official guide in the hyperlature documentation, hyperlature for documentation. This is the link which I have shown you previously on the starting page. And for the Docker version, there is no official guide there at 11, so, but I didn't find any information about this. So this is only my interpretation of how this could work. And yeah, both versions basically do the same. And I think it's the choice of the developer which version he or she would like to use. And when you compare this processes, then you see we have, we need some terminals for this as I have mentioned. And then the green ones are the binary versions and the blue boxes here are the process of the Docker version. And you see that we can have, so, in terminal one, first is that we have to download the official Fabric repository. So, and this is a part which you need. And this is, and this step is not needed when you use the Docker version. And then when you have this Fabric repository, then you have to build these binaries. So to build these binaries, you need this goal. This is the, all the, all programs, peer, order, config, TX, GAN, and other tools are built in written in Go. And then we have to build Go binaries for that. And we have also, we need also some build tools to build these binaries. And that's a preparation step. And for the Docker composition, when we use this in the Docker version, the only thing what we have to do is we can start directly after we have installed the Fabric. We have followed the installing steps from the official documentation. And when we have installed Fabric samples and we have tried to test network and then we are ready to go and can create this second Docker composition where we can start the development network. So, and here we have an, yeah, so that's a little bit different in the approach. And then the steps are the same. So the first step is the next step are the same. So the next step is that we create the Gannises block for this test network. This is a step which we have to do in both versions. And then we can start the order one. In the binary version, we have to start the order one. And for this, for that, we need also a configuration, of course. And this configuration is a sample configuration which is provided also in this Fabric repo repository. So this is how I would like, I would show you a little bit later. And here we will find the ready configuration also with the crypto materials and certificates which we need. And this profile is called a sample def mode solo profile. And then we can start the order one. And then the order starts in terminal one. So, and in the Docker composition, so we have in this Docker composition two services. One is the order service and one is the PS service. And when we start this, then we started with the same channel configuration and then we have the order and the beer running in a two Docker containers. And we have this all in the same window. So, and we don't have to start the beer in the terminal two. And that's the reason why we need one terminal less than in the binary version. So these are the steps until here. In terminal two, we have to start the beer. And we have to start the beer with a special option here. And this option is called beer chain code def. Chain code def. And when we start this in the terminal, then we can create, then the terminal is also blocked. So, and then we have to create and join the channel in terminal three here. As we have to create the channel and then we join the channel and yeah. And in this terminal three, we can start and stop the chain code manual. But in the first time when we start the chain code, we have to make all the steps to install, approve and commit the chain code, but only for the first time. And this is the process for version 2.2. When you have, when you use version 1.4, then you will not have this chain code life cycle policy. And there's the, but the process is the same, but it's the same how you do it in the 1.4 version. But the process to install a chain code is a little bit different. And then, and for the Docker version, we can in terminal two, we can create and join the channel. And then we can start and drop the, start and stop the chain code in this terminal as well. So, and here I have this approved process. So we have to do this approved process only once. So for the first, for one time, and then we can use the CLI commands to use so be a chain query and be a query and be a invoke to test our chain code here. And for the binary version, yeah, we need one terminal. So, and that's why the, because in terminal, the terminal one is blocked through the order. So, of course we can run this order in the background. So every process on a Linux terminal, you can run it also in the background, but then we will not see the output from this process. And some in the development, it's important to see maybe the outputs from the chain code and from the order and from the PR. And that's the reason why the terminal is blocked through the process for the program, which runs in the foreground and not in the background. Yeah. So, and here you can see a guideline, which steps you have to do when you use the binary version or the Docker. So, okay. So, and when we try to do this, so I have here, so we can look also into this in this repo. This is the, so this is the repo. And in this repo, I have documented all the steps. So you can use this guide and so we have two possibilities here. So we can do, we can do this binary edition or the Docker edition. So, and let us start with the binary edition first. And yeah, so larger. So I start with a standard folder here. So this is a simple Ubuntu box and there I've created the folder. I call it FabricDef and in the Fabric folder here, we have the FabricSamples here. That's basically, this follows the standard installation guide. So, and on the same level, I have created the FabricDef folder to run this. And the first step is that we have to clone this Fabric repo here. And when we have done this, then we have here a folder, it's called Fabric and with all the files which we need. And here you see also this sample config folder and in the sample config folder, we have all the configuration which we need to start the development environment. Also for the binary version and also for the Docker version. You can use it also for the Docker version. And in this folder, I think two folders are important to know. One is this sample config. So, and you hear, and here you see a config.tx.yaml file. Of course, we need the channel and this channel need the configuration and the configuration lives in this config.tx file. And then we need the query.yaml file and then here membership service provider folder with the crypto material for the TEPIDAS desk case. And then order yaml file as well. So, and this folder, this information we can use. And the second important folder is the build folder and there's a bin folder inside. And there we will have a peer in Aurora and then config.tx.yaml file. So, but this will, this free binary, this free binary files will be created when you build, when you build, so when you call it and make a command here. And this took some time and so, and I have created this before. So, and this is the reason why I have here this free binary files and with this binary files. Yeah, so one question here in the chat. So, when we follow official doc, we use binary approach. Yes, so in this, in the official documentation you have this binary approach. But when you think about this a little bit, so with this binary approach, you can do much more. So, you can also say, okay, we create a network, a Docker composition network, and then we create on a second machine, a peer, which runs as a binary version. And you don't, maybe there is a use case where you say, okay, I don't want to run this in a Docker container or on the Docker host. And then I can use also this binary version to run a peer as on a single machine in a binary version. And then I can create maybe a Node.js application as a client application. And then I can query this client and make my queries. So, for example, when you have a logging application or where you have to create a lot of data or I don't know. And then you can, and you take, must take care on performance, for example. Then you can decide to create a network where you have the binary version. Maybe it's a little bit faster. And you need less resources because of the fact that you don't need the Docker system for that. And then you can use also the binary version as well. But we also use Docker there. I don't know, I don't understand this question. So you have to, you have to choice. You can use both. And in the end, you have to decide which version is the best for you. In this presentation today, you will see both version and then you can decide what is the best fit for yourself. Okay, but when we clone this repository, then we have to notice these two folders. So these two folders are important for us for this example here. So, and then, so we can leave this. And then I have created a simple structure. So I've created the folder with artifacts. So it's empty. Then I've created the chain code folder with my chain code. So this is the place where my chain code, my Go files from the chain code lives. So here, the as a simple as a chain code, we will use it later. So I have copied this from the trip examples and then we will use this. So here we need the place where we can put our chain code and interact with it. And then we need the, later I will create a data folder. And with this in this data folder, the blockchain will be stored. So this is the place where we store the blockchain and it's also empty for now. So, and so that's a simple structure. You can name it how you like. And yeah. So, and then we have this, so. And the first step is always, but we have to put this path here into the path so that we can call p order and conflict here again. So it's useful when we use, we put this into the global path. And then we need, of course, this favorite conflict path environment and this conflict path environment should be linked to the sample conflict folder here. So, favorite knows where is our configuration here. And then we have the first step now is to use the conflict DX again tool to create the genesis block. And in here you see this is the profile and you can look into this. Do you see here the configuration of this sample def mode? And there are other configurations. So you can look into this file. And so here you have the profile section and then you have here different configuration samples. So it's also useful from the administrator side to look into this configurations and see how you can use the different configurations. But from the developer side, we have here ready to use profile and this is the configuration, also with the proper endorsement policy here. But it's not important here because it's only for testing. The only thing is that it works. But you can use the chain code with the CLI commands. So, but the important part is this profile is ready to use and that's why we use it here. And then we have to create the system channel and the genesis block and yeah. And the place where we create this is our artifacts folder. And then we can use this. And then you'll see here, the genesis block is created and we should have here the artifacts folder here, one genesis block file. And yeah, so the next step is that we can start the Ottawa system. And we can use this in two ways. So we can export this free Ottawa environment variables or we can use it also in the single command line. So I, for copy and paste, I use this single version, single command version. And so for a better understanding, so it's often better that we can use this expert command and then we have to have seen, we can see the single variables in a single way. So it's easier to understand. So, and we need three of them. So we need the place where the genesis block lives. Then we need the location from the file lecture. So that should be data folder in our data folder and this data order folder. And then we need the genesis profile type. So that's the sample def module and then we can start this. Now we will do it. So we use, so we need different terminals. And here I have some help for trucks operations commands. And I will try it here like this. So, and then we can start the auto here. And you see the auto is running and the terminal is blocked. And now we need the new panel. So we can do this with control B and quotes. And then we have split this terminal here in two. This is a little bit tricky. So it depends a little bit on the keyboard. So you have to practice this a little bit. And then, yeah, it works. So here you have help for trucks command and there's also a cheat sheet page on the internet. I've shown it several times here and the link is in one of these meetup support materials. And yeah, so auto is running. So, and the next step here is that we have to start, we have to start the peer. And for the peer, we need also some environment variables. So we need this core operation listen address, the file system path is should be under the data folder then, okay, the logging is not so important but we can do it. And then the chain code listen address. And of course, the important command is here, be a node start. And then we have here the chain code, be a chain code deaf is true. And when we copy this into the second terminal, and then we see that the beer is one. And then we have to split the window again, control B. So, and then we have control B and space. Then you can make the panels a little bit larger. So we have an ordering session. We have a panel where the peer is running and then we have to create the channel. So, and for the channel, we have to create, we have to use the conflict DX again, DX again file. And so I call it a channel, channel one. And in the artifacts, artifacts folder, we will create this channel creation transaction. And we use also this predefined sample single membership service provider channel profile here. And the conflict path is also important that we have set it in the terminal below. So we create the channel now and here you have this channel transaction file. And then we can create the channel. And for the channel, we need the order address. So send the local host and the standard part. And then we have here the output block and the channel transaction file and the channel name of course. It works as well. And then we can join the channel. And you see, we are successfully submitted the proposal to join the channel. And the next step is to use our chain code and to start the chain code container here. So we can go into the chain code folder and we have here the, so I think we need now any window. So here you have this standard chain code. This chain code is copy and paste from the fabric samples. And the chain code does only set the value and to get the value back. So it's like key value store. And then we can build this chain code. But sometimes you don't have this vendor folder. So in this vendor folder, there are all dependencies from the chain code which we need then we can install it with this command. And then we can build the chain code. So I will, no, it's not here, a simple chain code. So we move the chain code and then we build this chain code. And you see here, that's our chain code. And then we have to start the chain code by ourself. And this is done with this command here. So here's the path to the chain code, dot slash simple chain code. And now the chain code is running. So, and we need one more terminal. So, and then we have to approve the chain code and commit the chain code. But this step, we have to do only once. And these are the standard steps to install a chain code in the 2.2 version through this new lifecycle chain code environment policy or governments. And this is a command here, lifecycle chain code approve org. Then we can check this, check commit readiness. And then we have to commit this. So we need to approve this from organization, from our sample org organization here. We have only one organization. And then we have to commit it. And the check for commit readiness is, yeah, we can do it but we don't have to do it. We can skip this step as well. So the first step is that we approve this chain code. And you see it's valid. Then you can check if you are ready to commit your chain code with this command. And you see here, and you see here which organizations has approved this chain code. And we say only sample org is true but we only have this organization. And then we can commit it. So now the chain code is ready. And we have here a valid transaction. And then we can test it. So with the peer chain code invoke command we can call this my chain code. So because we call it here, my chain code, my chain code. So that's the chain code name. And then here we have the C option for the command. And when we can use this init function here to create them, then we have chain code invoke successful. You see here the committed block. And then you can create this. So, and you have here hello. So, and we see, yeah, and then you can see here what is, what about the chain code. And we can test the second one. Then if you're the block committed and then you get message to this hello to here. Okay. So, and this is how this works. So, but what happened when you change this chain code? So then you have, then again, you have to stop the chain code itself. And we can do this when we switch back in this panel, control the crew, you see the numbers. Control the crew, you see the numbers here. And with two, you switch into this panel here. And then you can control C and then you stop this. And then, and now we can modify. So I have here prepared some debug value so maybe we will put this here. So we have chain code, we have the import for the OS. So, okay. So now we have added the debug value, but only the asset name, the queried asset name should only be displayed when we deliver the special environment variable, the def mode enabled, for example, when it's not is equal, it's not equal to zero here. And so, but the important point here is that we change the chain code now. And now we want to test if this works here. So, and how we can do this. And yeah, we are in the chain code panel here and the step is that we have to build the chain code again. So we can build this chain code again. And then we can start it. And we can start the chain code with the same command. And we have here the enabled test mode. So we have here in this single line command also the environment variables. And we want that only when this def mode enabled environment variable is delivered to this chain code. And it has a random value. Like I gave the value, I set the value test, then the key should be printed. And then we start the chain code again. And now we switch back with contract B, Q and then the number, contract B, the number of the terminal. So, and then you can make your query again. So query two, and you see here, the asset is asset two is the MSG two. And one, no, this one is this one. And yeah, that's it. And now you can make, and then we can stop this chain code again like this again. So, and then we can build the chain code again. We can start it, contract B, Q, Q. And you see your changes. And this is the way how you can use the PR def mode in the binary version here. And the same we can do also with the Docker version. So, but for this, we have to close this. And yeah, okay. So, and for the Docker mode, so do we have for any questions here? Where can I get this MD files? Yes, cool, thank you, looks really cool. Yes, it is, but you have to get familiar with the keys. And the, I think for me, the difficultest part of Max is how you can scroll inside of a panel. So, that's the reason why I have this here. So, contract B, and then on the Mac tester to the function and the up or down keys. And then you come in a scroll mode. I think it's a scroll mode. And you can, then you can scroll up and down. And yeah, to leave this mode, you have to use the escape key. So, this works on a Mac keyboard. So, I don't know how is this on a Windows on the other keyboards. Is there any way to get the chain code? Do you mean this chain code? Yeah, this is official chain code. When we look here, you can find a lot of chain code examples in the, when you install the favorite samples. And here in the favorite samples, you have here a folder chain code. And this is the folder which I have copied. And yeah, but you've been to the marbles example, the marbles in private data collections, examples, you find here the FAP car. And in some folders, you find this is an external version. So in ferric 2.2 there is the possibility to use the chain code as an external service. This is an example. Then in some chain code folders here, you find the go version, a Java version, JavaScript version, TypeScript version, but not every example has all languages implemented. So this marbles example has only the go chain code here. And you see here the meta in file, meta in folder. And that means that the CouchDB is involved because we have here the index owner JSON file. This is needed when you want to use a CouchDB instead of level DB. Yeah, so until you find a lot of chain codes here, but you find it also here in the asset basic transfer. So here you find, this is a standard chain code and application code folder where you can find the proper chain code for this standard demonstration chain code here. Also with tests, with go tests here, yeah. And then you find also here, this is the chain code, yeah, and you have in Java and JavaScript and so on. And you have here also in the application folder, and then the application folder, you find here the JavaScript or better, Node.js version of the client from the client side. And this is needed to connect to use the chain code without the CLI commands. So CLI command is only for testing and for the administrator part. And the JavaScript client, the Node.js client, I think it's the standard language for the client side. And here you find how you can interact with an app.js. So this is the an express.js version. I don't know this is, oh, no, this is also a CLI version. But you will find all the commands you need to submit the transaction and here evaluate to query a transaction defined here as samples. So, and here you find all the chain code. Difference between asset transfer, basic and chain code folder. I think these folders are new. So you will not found this in your 1.4 version. So, and your 1.4 version only the chain code folder here. And this is, and oh, I think a large difference is that here is the application, the chain code. So maybe from the go side, here you can see the contract API. So with the 2.2 version you should use the contract API as an API to connect with the letter. And then 1.4 there wasn't this contract API. So this is a new version of this level of abstraction. And I think maybe that's the reason why they have this, put this here on the side and on this first level. So maybe that all people see that this is new. And yeah, and then the chain code here, the chain code folder, these are examples. These examples exists also in 1.4 version. So, and when we look at the SAC here, then you have here the shim implementation. And that's, I think maybe that's, I don't know. I don't know why this favorite sample structure is like it is. And I think this is because this is the old version. So all this, this APAC is also an interesting example because this is, in this example, it's also based on the shim scheme. And this is an asset attribute chain code example, I think so. So in this example, attribute-based access control, this is the right term. So this is an example for an attribute-based access control chain code. And with this, you can, when you make a transaction, then you will have to use a certificate from a user and this user can have some properties. And with the chain code, you can read these properties with this here. And then you can say, okay, when this certificate has the property, maybe a group or department development, then you can write in the chain code, you can use the write function or the store function, the put function, for example. And when you, a user which belongs to the marketing, for example, then your certificate has the attribute marketing or something like that. And then when this user tried to use this function, then you will receive an error, for example. So this is for permissions. So, and this is an example and this is attribute-based access control. This is also based in the one point, so started in one point version. And this is also based on the shim here. So I don't want to go too deep now in the chain code development. So this is, so for this, we should make a session directly on chain code development. So I show you the examples here, but I don't want to go too deep into the chain code development because this session should be around the installation and configuration of the chain for the development environment. So, and this stop and this shim here, if you're confusing. So this is, this is the standard go language. So, and so you have to look into the go documentation to understand what the first parameter and the second parameter here means. So, and yeah, but you find here other examples as well. So the commercial paper is also a good example where you'll find helpful tools. For example, one important point is here, the under organizations application. So here, the add to wallet script here. This is very helpful here. So we need the, when you use this, there's no chance application and then you connect to the fabric network, then you need the user and this user profile or this user credentials, or this identity is stored in your wallet. And then you have to enroll and create a new user. But this is only possible when you have been through a running. And in this development environment, we don't have in physics a running so that we can register, register and enroll and your user for a demo application or for something like that. And when we, when we create with the crypto material for every organization to use us on the default way created. And I have to go over, but thanks for doing that. Bye. And in the default configuration, two users are created in admin user and the user one. And with this script, or with the source code here in this script. So I think you can use it, but you have to change the paths here. Then you can convert the user one to a wallet identity, which you can use in for your Node.js application. And that's an helpful CLI tool to convert an existing identity to the wallet for your client application. And it makes sense to look through these examples here. And you see here a lot of examples where you can learn to do different things here. From the shell scripting side, from the chain code side, from the go side, Java side and so on. So a lot of best practice examples here. And you can find, you can look what is a good solution for yourself. Okay, so yeah. This is the short side note on the different chain codes here. So you can copy all this chain codes, all my examples, mostly from this official documentations here from your favorite samples here. Okay, so now let's move forward and go to the second example. And this is the example with the Docker version. So, and for this, we need the Docker composition. And I have prepared here in the favorite samples. And yeah, so I created here as a folder. I called it deaf network. And in this folder, so let's jump here. We have basically the same structure. We have an artifacts folder with a chain code folder with the simple as a chain code example here. We have a folder with ledger data. So, and then we have here the sample configuration. This is the same sample configuration we have used before. So I have copied in here this into this folder. And then we have a Docker composition here with an order and the PR. So, and we need this end file. Don't forget this environment file. So this dot end file, these are environment files for the Docker composition. And yeah, so it's basically a little bit copy and paste from the test network, from the official test network. And the only thing what we have to change here is that we take care on this compose project name. So that should be the same like the folder. So I'm deaf network here because I called my folder deaf network. Yeah, so, and we need this Docker composition. So with one order and one PR. And you see here the same environment variables. Basically the process is the same and we need the same elements but the configuration is a little bit different. So when you are more familiar with Docker then you are fine if you use the Docker version. And when you're not so familiar with Docker when you do it a little bit more with the binary versions or work with the binary versions then you can do the other way. So, and important here is what is important. So, okay here, I mean, for the order or configuration we need the sample config membership service provider folder. Then we need the genesis block and we need the place where the order puts his data, his ledger data. And we mount this into the container here. So, and that is what I have meant before. When you use the Docker version you don't sometimes you don't recognize where all this data lives because you mount the folder to a path. So this is a copy and paste action sometimes. And yeah, and it works all the time as long as you use the Docker composition. And but when you switch to a binary version then this path is on your local machine. And also this path is on your local machine. So, and that's important to know that you have and then when you use the binary version or persistent version and the files are stored in this location here. And yeah, yeah, and for the be at the same here. Yeah, so the gossip, for example, gossip bootfrip we don't need this because we only have one peer here. And the volume here also here only the ledger data. So you see here we mount this on bar hyperledger production. So, and then here the command important, you see peer chain code depth is true. Okay, so that is this, yeah. And then a sample config. So is, yeah, here we can look into this. That's the same I have shown before important here the profiles. Yeah, and you see here. And that's also a good place to learn how you can set up your profiles. In different configurations here you see old Kafka configuration. So, because the Kafka is deprecated in 2.2 so we should all should use wrap tier also here and so on. So there are a lot of different configurations. The core YAML file, that's an interesting part. And because have you ever asked yourself where all the environment variables came from and which environment variables are available? And all environment variables came from the order YAML file from the core YAML file here and for the order from this order YAML file. So when we look into the core peer listen address, so then this is the environment variable here, so, yeah. And this is, and when you try to address this address here then, yeah, you mean, then this is your variable name. So, yeah. And this is the prefix. You can say it's a prefix. So, all variables, all values here from the peer section, yeah, have the prefix core peer. So, yeah, so, yeah. So, yeah, so, yeah. So, yeah, so, yeah. So, yeah, so, yeah. So, yeah, so, yeah. The prefix core peer. And then listen address, network ID, chain code address, for example, yeah, and so on. So you can address all this configuration values with the environment variables here with the same schema. So, yeah. And for the order YAML, it's the same, but the order YAML use order YAML here, And you can find also all auto environment configuration variables here into this listen address, listen address, listen pod. So we can change this Genesis mode. This is in this file. Maybe I'm wrong, but yeah, but for the environment variables of the core of the peer, you will find all this environment variables here. But also for the Ottawa, okay, I have to look later. Okay, so, and yeah, and the steps are here. So we don't have to. So the only thing is what we have to do is we create a folder with this small subfolders. We have to create, we have to copy this sample config and the environment variable and this end file. And then we can copy also the Docker composition from the test network. So, and then we can modify this, blah, blah, blah. So this you have seen Docker network. This is the same name. And then customize the Docker compose file. So we have to, we need only the order and the beer here. And yeah, and we have to change the order end points here. Okay, so, and so, and that's it. And then we can create the artifacts. So we have to set the environment variables for this new. And so let's check if this is empty. Yes, so, and this, the creation of the Genesis block is the same as we have seen before. We have a Genesis block here. Then we can create the channel, transaction in the same way. And then we can start the network with Docker compose up. Now both the order and the beer are running. And then we can switch to the contract, the cool one to the second terminal. And so we have to switch to favorite, favorite centers, definite work here. And we have to set the profit part. And then the next step is the creation of the channel. This is also the same step as in the binary version. Yeah. So we'll see if block zero and then we can join. So okay. And then you can switch into our chain code folder. Here we have the simple asset chain code. Yeah, and that's the same here. So, and you see here, you have a lot of the folders here, not the chain code, but we can look at later. So, and as simple as a chain code. So, okay. So that's the same check chain code without our modification in the get function here. And yeah, we try to do the same here now. And then I have here already installed the vendor. So the vendor are the dependencies for this chain code. And you can see also if you look at three vendor, as you see here. So, and now let us scroll a little bit. Control B, let's run here. Ha, it works. And you see here on the right side, I think now you're in the scroll mode, and you can scroll up in this terminal. And with the key down, you can scroll down. With the escape, we can skip this mode because we cannot scroll here with the mouse pointer. And maybe that's a little bit from the practical aspect and disadvantage we can use here for SSH terminers. And then we have a little bit more comfor in the case of scrolling. But the good thing of the Trimax terminal is we can leave our terminal and without stopping the system. So we can detach from this Trimax session and then we can log out from the terminal. And tomorrow we can come back and then we can reattach to this session and all this running. And that's the good thing of the terminal multiplexer. So you can have this configuration running and you can stop your SSH connection to the server. And in tomorrow you can come back and then you can start with your work until and all is running. So, and that's, I will show you this then in a second how this works. And that's really the cool thing because when you use the terminal and you have this running in terminers, then when your terminal session ends, also it means that your process ends and then your system is down because the session is closed then also your process is closed. And that's the really cool thing that you can have this configuration in the background running and then you can attach and reattach, detach and attach to this session. Okay, so let us quickly build this Jaincode. So, okay, now we have built this Jaincode and then we can start it in the same way, small typo SSHC, okay. So now the Jaincode is running and then we move to the next terminal. So we can do X and we kill this panel So, now we are, okay. So, and now we have to do the same approve process, the examples, definite work, set the conflict path variable. So, and then we have to approve this Jaincode you can check the readiness we can commit the Jaincode. And now the Jaincode should be valid and ready. And then we can do the same. So, test our Jaincode, let us test and we have Jaincode successfully. And then we create a Jaincode, roll it. So, we can create a new version of this value. Look, roll into it. Yeah, and then when we change this Jaincode, so we do the same control B to one and then we control C and we can close this. And then we can make the same modification here. So, I will do it only once. So, we need this OS package involved, so it's here. And yeah, and then we only have to do is to build the Jaincode and to start the Jaincode. So, and then we can start it. Control B, cool two, and then nothing happened because we did not use the def mode environments variable. So, there is no output, no point here, equal one. So, we stopped it, we stopped it and then we can use this, yeah. And you see, I said one. Now, you can change your Jaincode very easily and also in a quick way. I changed something, I build it new and then I started the Jaincode. I switch to the second terminal. And now, I have tested it and you see here, this is my change, this was my change. Okay, so, and then I say, okay, I'm fine for today. And now I have to leave. And now, we can say, Control P D and now we have detached us from the session. And now, we can close this terminal and that's it. But in the background, the development environment is still running and we can look it to Max LS. We can see, okay, we have here one terminal, one window one. So, you can have different terminals in the back front one. So, yeah. And then you can detach to this. To Max, attach option T and then the name def and here we go. And I think that's the most advantage which you can have with some terminal multiplexer when you use this def environment. So, and somewhere to all this stuff here, to this environment here. So, my environment here, this is an Ubuntu box which is running on digital ocean. And the blockchain is also running on digital ocean. And on my local machine, I only use a visual studio code editor and I use the SSH favorite extension, SSH extension and I connect and I can connect directly to my virtual machine in the cloud and I can work here as I would work on my local machine. But I don't have to install anything on my machine here. And I think that's a really cool developer environment. So, and we don't, so you can do it also on windows as well. So, when you work on windows, you can also use visual studio code with the SSH extension but you can use the Linux environment and you don't have problems with file names and file paths and something like that. And I think that's a pretty cool environment here. So, okay. Of course, you can hear different versions of chain code. So, the system is the same. So, when we say we have a ledger and then we have a channel. And on this channel, we can install different chain codes. So, you can test also a second chain code in this configuration to the same time because we can install on a channel different chain codes. And yeah, so it depends on you and on your fantasy how you can organize your development environment here. Okay. So, is there something interested here? Okay, no. Yeah. I think I'm now on my end and yeah. So, today you have seen two possible approaches how you can easily test your chain code. You can use the binary version to this version. You will find your official documentation here in this link, look back here. So, one in chain code in depth development mode. So, and look here. This is the release 2.3. So, when we look at the stable version 2.2, we don't have this here. Yeah. Don't ask me why, I don't know. And yeah, and the Docker version is not documented. And that's the reason why I have created this GitHub repo here. Yeah, the Docker left mode. And here you find all the steps which we have seen today. Yeah. So, I think we are done with the overview and the presentation. Yeah. Do you have any questions? Are there any questions in the chat? Oh, thank you. So, it is a better solution for low RAM machines. So, it is a better solution for low RAM machines which have lost of square root with the terminal at all. Yeah. No, it doesn't, no, no. Schmuck's terminal also run after shutdown system. That is, I don't think so, but this is a question I have tackled a while, but some, I found some scripts, but I think that will not work. So, when you restart the machine, I don't want to say it will not work. So, some cool guy has found, I'm sure some cool guy has found a solution for this, but normally the smuck session is lost when you restart your machine. So, you have to make a script. And I think I can remember, I saw a script, but I haven't used it that you can store this smuck session when the server is shut down. And when you restart it, then you can restart, we assemble or we set your smuck's configuration for these sessions. So, that's the only disadvantage and the scrolling is for me a problem. So, but when you are familiar with the terminal, with the keyboard, then I think this is a good choice to store or to use it. Now, other questions? Sorry, this person is a drugstore as I know. Should we all connect on WhatsApp to share our thoughts and ideas and learning? Share. We have already a Slack channel. And you can, I think I could, if you want, I could post the invitation link here in this chat and in this Slack room, in this Slack channel, you can ask your questions. But I have to say, at this time there is no much, there's not so much traffic in this Slack channel. So, but yeah, so. But we don't need the WhatsApp group, so we can use the Slack channel for this. We will come, clone some of our projects. If you clone someone's favorite project, I don't understand this question. We have to get to these instruction files, so I missed it earlier. So, okay, see you in the chat. Slow, the current Docker, oh, Antonia has left one. Okay, so, please share the link. So one moment, I have to find it. I hope this is the right one. Okay, so any other question? Please have a session on end-to-end basic application. So, do you mean a session, how you can write the Node.js application to connect to the letter? Yes, so in this, we can do this. Yes, so I will see. So for the next session, I have planned, maybe that would be good idea. So for the next session, I have planned a comparison between, so it's about the keys. So when we query something, when we store something in the blockchain, then we need the key, so, and the value. That's all. So to store anything in framework, we need the key and the value. So the value, the key is a string, and the value is binary data. And binary data is an object, is in a way, whatever is, is, and then, but we can use, but when we use this key, then we can query an asset into the blockchain, but the key is a string. So it depends on the used state database. So when we use a level to be as a database, as a state database, then we can only query the key or a composite key or a key range. So, and the interesting part is the composite key. And we cannot make in the level to be a witch query or to query a property from the asset, for example. So when we need, when we have a use case, where we have to query, when you look at the car example or the fab car example, there you have colors. For example, a property, it's called color, and you want all red cars to create all red cars. Then you cannot do this with the level to be. So you have to do couch to be. And when you use couch to be, then you can make which queries and all, and you can do all the queries which couch to be has. So you can use aggregation functions, you can use whatever every query you can do in couch to be. And maybe in the next session, I would like to show how this fits together and how we can use a composite key to query some data. Because I used this composite key in a project last week. And then I was thinking, okay, this is a good example to use the prototype, the composite key. And then I observed that we cannot query a partition part of the composite key. So you have to use always the prefix from this composite key. So you can, that means that you cannot query when you have a composite key, which is established with three parts, then you can not query only the last part of this composite key. So you have to query the whole key. So you can only query part one, you can query part one and two, and then end one, and part one, two, and three. So you only, and you cannot query the part, but three alone, so for example. And it was a new, a new, impact, no, I don't know, impact, no. So this was, this was really new to me. And so, and this I think, this is a good example how you can do to explain how things are stored in fabric and how we can query this. And we don't store keys in data decrypt, we don't store keys. When you think, when you mean with keys, credential keys or certificate, yes, so in the database you don't store, but that's not true. So you can store the keys also in the database, yeah. They are because, and there is, I think the example for this is also in the fabric samples and this example is the, I think commercial example, and we can use, ah, no, no, no, I'm wrong, not the key, so map, part one, and part two, and part three, ah, no, no, no, I'm wrong, not the key, so map, part keys. So when we use the client application, we need the local wallet and this local wallet, we need the private key and some credentials from the user. And this keys we can store in a database. So, and we can store it also in the memory because we can use different wallets. So we can use a wallet for the file, as a file wallet, you know, in the folder, we can use a wallet in the memory. And with this in the memory, we can use also a wallet in my SQL database, for example, or in a Postgres database, so, and this example is with a Postgres database. I think I saw this on a Fisher IVM site or in the commercial paper site. So, but it's a difficult questions, but when you mean you want to store your keys, your certificates, then you don't, I think it's not a good idea to store keys in a database. So, Fabrik under, under, under, so has this hardware key storage, HSM, hardware storage module extension, I think, so you need a secure place where you can store your certificates. And with keys, you mean the certificates. Okay, so I think now we are on the end. Thanks for attending the session. Later, you will find also the recording and I will put the slides also on the meetup in this meetup, on the meetup page in this meetup form, so that you can receive this. Okay, then thanks for attending the session and have a good day, night, whatever.