Forum Discussion
Post ProdigyHow creating a Python custom library
Hi pmscorca,
That is correct. Here is an example of a custom workload with the extensibility toolkit: https://community.fabric.microsoft.com/t5/Extensibility-Toolkit-Gallery/Fabric-Job-Registry/m-p/5006346
Super UserHi pmscorca,
It might be worth while to join the Fabric Discord that I run (link in my signature) so we can have a more conversational exchange here.
A custom workload will hide your code the same way Micorosft hides their code. FOr example, when you make a pipeline, you don't see the code behind how the pipeline works. When you make a copy job, you don't see the underlaying code for how the copy job operates.
Those are both examples of items inside a workload. WIth the extensibility toolkit, you can create your own custom Fabric Item types that will appear to users who install the workload in their tenant.
Now if your goal is to re-sell Fabric as a solution, maybe a workload isn't what you want.
Do you intend your solution to run on your Fabric tenant permenantly, or do you intend your customers to purchase fabric and then deploy your solution?
If you intend for everything to always run on your tenant/capacity, then you can take the approach that Epic Systems is taking with Cogito Cloud, where they manage the entire thing end to end and make the data available via B2B sharing. In this scenario, because all the notebooks and code is in your tenant, your customers can't see it so there is no need to do anything special to hide it.
If you intend to use your solution as a selling point and expect your customers to pay for a fabric capacity as well as your solution, then a custom workload is what you're going to want.
pmscorcaHi, thanks for your reply.
Let's assume that my solution is composed of a lakehouse, a pipeline for data ingestion, a notebook for data transformation, a semantic model and a set of Power BI reports.I don't want to offer a service on my tenant; it needs to be on the customer's tenant as much as possible.
In a such case, you say that implementing a custom workload is the right way to follow, ok.So, what does a customer workload create on the customer tenant? Lakehouse plus pipeline plus notebook plus semantic model plus reports? F.e. if the custom workload creates a notebook, is the related code protected?
- tayloramy
Hi pmscorca,
A custom workload can create anything that you can code.
There's built in APIs to access system storage, and Fabric has lots of APIs for creating lakehouses, accessing lakehouse data, ect.
I would recommend that you don't use a notebook for data transformation, and instead build a "data transformation" item that does everything you need it to do, and keeps the logic hidden from the end users.
Once you have built this out, then you need to get it published to the Azure marketplace, and from there anyone can purchase it from you.
Note that code is only protected for your custom item types, so if your workload creates a default item type like a notebook using the APIs, then that will behave just like any normal notebook and the customer will be able to see the code.
However if you create a custom "transformation" item type, then your code will be hidden.- pmscorca
Hi, thanks for your reply.
So, in a custom workload it is enough to create some custom items in order to protect the code and all these custom items can reside on the customer's tenant, isn'it?
Thanks