SDK: Building a Module (Advanced)
- 13 Nov 2024
- 3 Minutes to read
- Print
- DarkLight
SDK: Building a Module (Advanced)
- Updated on 13 Nov 2024
- 3 Minutes to read
- Print
- DarkLight
Article summary
Did you find this summary helpful?
Thank you for your feedback
Custom Module for v8.14 or lower:
Customers who are using Decisions version 8.14 and lower should refer to the GitHub Branch 7.x to build the module.
Breaking Change on upgrading to v8.15 and above:
Customers who are upgrading to Decisions Version 8.15 should be aware that Custom Modules have transitioned from Module.Build.xml to Module.Build.json. As a result, it is necessary to rebuild their Custom Module.
Preferred steps to Rebuild the Custom Module:
Preferred steps to Rebuild the Custom Module:
- Navigate to the Decisions GiHub: Example Custom Module.
- Ensure the Branch is set to 8.x.
- Download the code and rebuild the module following the steps mentioned in the article below.
Custom modules are created by users to add or extend certain functionalities and to link together different types of custom functionality. While custom modules do not require .dlls, it is common to build custom code in a .dll. Using a custom module may involve grouping exported Decisions objects, custom Flow behaviors, and/or step implementations together in one module, integrating custom Flow or step implementations with a third-party library, etc.
If a custom module needs to be updated, refer to the Updating Custom Modules section.
Creating a Custom Module
- Install the latest version of Decisions locally. For more information, refer to the Installation Guide.
- From GitHub, download the Custom Module by selecting Code > Download ZIP.
- The example module is named "CustomModule". Rename files to match the name of the module that is being created.
- Open CustomModule.csproj, CustomModule.sln, Module.Build.json, and build.proj and rename instances of "CustomModule" to match the module name.
- If needed, update the NuGet package reference in the CustomModule.csproj file to the correct version of the SDK.
- Add a reference to any external or third-party DLLs.
Module.Build.json Element Use Relevance Description CoreServicesDlls Most commonly used This folder contains a DLL or multiple DLLs that define a project's Flow steps, Rule parts, customizations, behaviors, initializer code for setup, and more. If these files have any Web Services registered in this folder, the user will get corresponding ServiceClient DLLs in the ServiceClientDlls folder. These are created by the CreateModule.exe tool. ReferenceDlls Required if third-party dlls are used Used to store third-party dependencies for a module. CliDlls Most commonly used See note on CoreServicesDlls. This folder does not usually contain any custom assemblies, only those generated during module build. WebPages Not typically used HTML or ASPX pages go into the web host's root directory. This folder must contain zip files that are unpacked on module installation. The unpacked files become peers to the Login.aspx page. This folder may contain folders, and those folders will be maintained. MvcDlls Not typically used Folder for compiled Dlls of MVC views and controllers MvcViews Not typically used These are additional MVC Views that are hosted in the Decisions.Web. The host is the primary user interface. MvcViews can be used to add additional view controls for pages and forms. These files go to the installation's Web Host/HUI virtual directory. HUI is the virtual directory that serves the HTML portal to users. AgentDLLs Not typically used Extra DLL files for adding the capability to the Decisions Cloud to Site Agent. If not using the agent and extensions to the product do not need to be run through the agent, this folder can be safely ignored. SQLScript / MySQLScript / OracleScript / AzureScript Not typically used These are database scripts that will run when the module is deployed. These are often used to add tables or stored procedures that this module relies on. ObjectsToImport Commonly used Flows, Pages, Reports, Rules, and Folders that have been built by the Decisions designers and exported from Decisions using the Import/Export function. These should be .decObj files. - Implement the module functionality by adding class files or custom code.
- Run BuildModule.ps1 with PowerShell to build a .dll and create Module.zip. Note that MSBuild is required to build the project. This builds the DLL file and creates the required module zip file to be deployed in Decisions.
- Stop the Decisions service and place the zip file into 'C:\Program Files\Decisions\Decisions Server\CustomModules'. Start the Decisions Server service.
- Include any custom images inside the CustomImages folder of the Module zip file. Refer to these images in CSS within MvcStyles to utilize them in the module.
- Once the Module is deployed, install the Module.
- If any changes are required, make the changes to the code.
- Run BuildModule.ps1 to deploy changes and repeat as needed.
Debug
- Attach IDE debugger to Decisions.Web.Core.exe process.
- Add breakpoints.
Best Practices
When creating a custom module, keep the following best practices in mind:
- Always version modules.
- If issues arise, please refer to C:\Program Files\Decisions\Decisions Server\Logs.
For further information on Modules, visit the Decisions Forum.
Was this article helpful?