Custom Code files for EngageIP can be stored in the EngageIP source code repository system regardless of whether they were written by LogiSense or other developers. The following sections describe the naming conventions for folders, files and build artifacts when the custom code file for a customer is included in the EngageIP source code repository system.

Folder Structure Naming Convention

The folder structure on the file system must reflect the namespaces and folder structure in the C# solution. Files are placed in the Customer folder in the C# solution as outlined below.

Folder	Content Guidelines

Folder	Content Guidelines
Config	These are classes that are used for configuration. For example, FileMoverSettings
Database	All SQL files must be placed here. This includes any views, tokens, and other objects. Typically these are SQL files. Any .txt files that are actually SQL files should have their extension changed to .sql and placed here
EventHandlers	All UUIH classes and classes inheriting from IAction must be placed here
Feeds	All CDR/UDR Feeds must be placed here. All Feed Processors should also be placed here
Hooks	All Hooks must be placed here. These types are defined in Logic.Hooks.cs. Examples are IInvoiceClosingHooks, IInvoiceReopenedHook, ITicketStatusChangeHook, etc.
Installers	Used for any ICustomCodeInstaller stand alone classes.
Jobs	All Jobs that inherit from IJob must be placed here
PageExtensions	All javascript, css, and classes that extend the UI must be placed here. This is typically seen with classes inheriting from IDynamicAction, ICustomPermissions and using Castle.Monorail
Reports	All Custom Report classes
ShellScripts	Any Shell/PowerShell scripts must be placed here. For example, Batch files (*.bat)
Templates	This is where any xslt template files must be placed
WebServices	All asmx, wsdl and related files must be placed here. Typically these are WebService.cs, WebService.asmx, WebService.wsdl

A concrete example for customer names of Acme, QuickSwitchNetworks, and RedBanana would look like the following:

Complex Files

Some of the test files contain an IAction, IJob, etc in one to encapsulate one feature and overcome the limitation of not being able to share code between custom code files. The location would be picked currently for where it makes most sense based on what the file is doing. For example, a Job may also have an installer in the file, it would go under the Jobs folder.

File Naming Conventions

Files must be named so that it is clear who it is for, what is is doing, and what type it is. The format is as follows:

Format

The 'Type' is a general description on what the file does. Generally this can determined by what folder the file was placed in. When the files are deployed the folder structure is lost. This naming format gives anyone the ability to understand what the file is about by glancing and the name.

Type	Description

Type	Description
Feed	Data Feed
Processor	Processors (pre/post)
Workflow	a workflow (single and/or multistep)
Job	Scheduled Job
Hook	WebHook
Action	Action/Dynamic Action
Report	Custom Report

Examples

AcmeBroadWorksFeed.cs
AcmeNetworkRatingProcessors.cs
AcmeUUIHWorkflow.cs
RedBananaUserAttributePaymentDeclineDeletionJob.cs
QuickSwitchNetworksRegulatoryRecoveryFreeHook.cs
QuickSwitchNetworksDataExportAction.cs

Build Artifact Naming Convention

EngageIP Custom Code build artifacts have the file name format of <Customer>-<Release>- <buildNumber>.zip.

For example, Acme Corp. from an 8.0.0 build with a release candidate build #14 would look like this:

Acme-8.0.0- RC14.zip

Inside the zip file will be the versioned custom code files. Each file has the format <customer><Purpose><Type>-<version> .<extension>

For example:

AcmeBroadWorksFeed-4 .cs
AcmeNetworkRatingProcessors-1 .cs

On each file the version will increase if the file changes relative to the last build of the file. These versioned artifacts are should be what's uploaded to confluence.

v9 Documentation

Custom Code Folder Structure and Naming Conventions