Описание структуры временного проекта скрипта
ELMA RPA генерирует проект (.csproj) со структурой:
Наименование файла | Краткое описание |
---|---|
Script.csproj | Файл проекта. В текущих примерах заменено с другими названиями. |
Context.cs | Файл с исходный кодом контекста. |
Program.cs | Файл с исходный кодом консольной программы для отладки скрипта без робота. |
ScriptActivity.cs | Файл с исходный кодом скрипта. |
Directory.Build.props | Ссылка на ELMA.RPA.SDK (<Путь установленного ELMA RPA Designer>/ELMA.RPA.SDK.dll) |
Выше представлен минимальный набор файлов для проекта. В реальности набор файлов может отличаться. Для сложных скриптов скорее всего потребуется дополнительные исходные файлы.
Пример проекта с пустым скриптом представлен в Template.
Файл проекта. Содержит параметры проекта. Самый главный момент, который может пригодиться, - это то, что в этом файле вписываются зависимости (пакеты NuGet или внешние dll)
Пример содержания файла:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<RootNamespace>ELMA.RPA.Scripts</RootNamespace>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="MailKit" Version="2.9.0" />
</ItemGroup>
<ItemGroup>
<None Update="config.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
</Project>
Для тех, кто никогда не встречался с такими проектами csproj, но хочется немного понять что тут такое:
Первый блок содержит основные параметры, такие как тип выходной сборки (в данном примере исполняемый файл), используемая(-ые) целевая платформа (в данном примере net5.0) и т.д. Это не так интересно в рамках скриптов для ELMA RPA.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<RootNamespace>ELMA.RPA.Scripts</RootNamespace>
</PropertyGroup>
</Project>
Второй представленный блок - список зависимых пакетов (NuGet). Вот этот блок может оказаться важным. Можно работать прямо тут, не используя графический интерфейс менеджера пакетов NuGet в Visual Studio, а также если работаете без Visual Studio (что вполне можно без проблем). Во всех представленных в данном репозитории примерах можно тут посмотреть какие пакеты подключены и просто скопировать в свой проект.
<ItemGroup>
<PackageReference Include="MailKit" Version="2.9.0" />
</ItemGroup>
Далее следующий блок представлен как пример. Тут просто указан файл, который нужно копировать в выходную папку. В данном случае это некий конфигурационный файл. Это, возможно, никогда и не встретится и не понадобится. Но как минимум в примерах может такое встречаться.
<ItemGroup>
<None Update="config.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
</ItemGroup>
На самом деле таких и других блоков может быть очень много в реальных проектах разработки больших программных продуктов, ведь это распространенный формат проектов разработки, а не только для скриптов ELMA RPA.
В данном файле содержится описание класса контекста процесса. Т.е. для всех контекстных переменных, которые настроены в дизайнере ELMA RPA, будут автоматически созданы соответствующие свойства в данном файле. Не нужно изменять тут, дизайнер ELMA RPA и так "знает" какие переменные и будет потом всё равно генерировать новый файл. Это прежде всего создано для удобства работы с временным проектом скрипта.
В данном файле описан класс для работы в консольном приложении и создается исключительно в целях тестирования и отладке кода скрипта вне робота. Ниже представлен стандартный сгенерированный файл.
using System;
namespace ELMA.RPA.Scripts
{
/// <summary>
/// Используется только для целей debug в внешней IDE
/// </summary>
class Program
{
static void Main()
{
var context = new Context();
var scriptActivity = new ScriptActivity();
scriptActivity.Execute(context);
Console.ReadKey();
}
}
}
Что тут происходит?
- Инициализируется объект класса Context, в котором описаны свойства (контекстные переменные). При необходимости можно далее присвоить значения контекстным переменным. В примерах частенько можно встретить заполнение контекста какими-нибудь тестовыми/отладочными данными. Это нужно понимать как будто у нас выполняется работ, что-то делает, какие-то переменные были заполнены при запуске, какие-то переменные заполняет сам робот и вот нужно уже выполнять скрипт. И мы по сути избавляемся от необходимости выполнять робота до этого скрипта и сами можем предзаполнить переменные. Конечно это не сравнится с реальной работой робота, но позволит проверить работоспособность скрипта и отлаживать, позволяя исправить какие-нибудь ошибки еще до выполнения в самом роботе.
var context = new Context();
- После инициализации контекста (и при необходимости заполнение контекстных переменных) инициализируем объект класса ScriptActivity. По сути этот класс является для нас целевым. Этот класс и представляет сам скрипт.
var scriptActivity = new ScriptActivity();
- Далее происходит вызов метода Execute (на русс. Выполнить), в качестве аргументов является объект контекста, который мы инициализировали ранее. По сути это тот самый метод который будет выполняться в самом роботе. Это как точка входа. Например, метод Main для консольной программы является точкой входа, так и метод Execute является главным методом скрипта.
scriptActivity.Execute(context);
В примерах можно встретить, что используется несколько объектов класса ScriptActivity. Это используется только для примеров и означает, что мы как бы сразу в одном проекте проверяем несколько скриптов, которые выполняются друг за другом. Контекст же один и проще работать сразу в одном проекте. Между выполнениями скриптов мы можем менять/дополнять контекст, как будто бы эмулируя работу робота между выполнениям скриптов. Но еще раз, в реальных временных проектах имеется только один скрипт. И такая хитрость может использоваться лишь при удобстве разработке, чтобы не создавать несколько отдельных проектов, и вот тут в примерах.
Основной файл скрипта. Тут описывается класс ScriptActivity, у которого обязательно должен быть стандартный метод Execute. Писать уже про это нет смысла, т.к. выше суть уже написана. Ниже лишь представим содержание стандартного только сгенерированного файла системой ELMA RPA:
using System;
using System.IO;
using System.Text;
using System.Linq;
using System.Collections.Generic;
using ELMA.RPA.SDK.Commons.Params;
namespace ELMA.RPA.Scripts
{
/// <summary>
/// Экземпляр данного класса будет создан при выполнении скрипта.
/// <summary>
public class ScriptActivity
{
/// <summary>
/// Данная функция является точкой входа.
/// <summary>
public void Execute(Context context)
{
return;
}
}
}
Тут return;
просто так генерируется ELMA RPA. По сути в нем нет смысла, можно и без него.