Skip to content

Описание структуры временного проекта скрипта

Gennady Zykov edited this page Apr 8, 2022 · 2 revisions

Краткое описание

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.

Описание по стандартным файлам проекта

Script.csproj

Файл проекта. Содержит параметры проекта. Самый главный момент, который может пригодиться, - это то, что в этом файле вписываются зависимости (пакеты 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.

Context.cs

В данном файле содержится описание класса контекста процесса. Т.е. для всех контекстных переменных, которые настроены в дизайнере ELMA RPA, будут автоматически созданы соответствующие свойства в данном файле. Не нужно изменять тут, дизайнер ELMA RPA и так "знает" какие переменные и будет потом всё равно генерировать новый файл. Это прежде всего создано для удобства работы с временным проектом скрипта.

Program.cs

В данном файле описан класс для работы в консольном приложении и создается исключительно в целях тестирования и отладке кода скрипта вне робота. Ниже представлен стандартный сгенерированный файл.

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();
        }
    }
}

Что тут происходит?

  1. Инициализируется объект класса Context, в котором описаны свойства (контекстные переменные). При необходимости можно далее присвоить значения контекстным переменным. В примерах частенько можно встретить заполнение контекста какими-нибудь тестовыми/отладочными данными. Это нужно понимать как будто у нас выполняется работ, что-то делает, какие-то переменные были заполнены при запуске, какие-то переменные заполняет сам робот и вот нужно уже выполнять скрипт. И мы по сути избавляемся от необходимости выполнять робота до этого скрипта и сами можем предзаполнить переменные. Конечно это не сравнится с реальной работой робота, но позволит проверить работоспособность скрипта и отлаживать, позволяя исправить какие-нибудь ошибки еще до выполнения в самом роботе.
var context = new Context();
  1. После инициализации контекста (и при необходимости заполнение контекстных переменных) инициализируем объект класса ScriptActivity. По сути этот класс является для нас целевым. Этот класс и представляет сам скрипт.
var scriptActivity = new ScriptActivity();
  1. Далее происходит вызов метода Execute (на русс. Выполнить), в качестве аргументов является объект контекста, который мы инициализировали ранее. По сути это тот самый метод который будет выполняться в самом роботе. Это как точка входа. Например, метод Main для консольной программы является точкой входа, так и метод Execute является главным методом скрипта.
scriptActivity.Execute(context);

В примерах можно встретить, что используется несколько объектов класса ScriptActivity. Это используется только для примеров и означает, что мы как бы сразу в одном проекте проверяем несколько скриптов, которые выполняются друг за другом. Контекст же один и проще работать сразу в одном проекте. Между выполнениями скриптов мы можем менять/дополнять контекст, как будто бы эмулируя работу робота между выполнениям скриптов. Но еще раз, в реальных временных проектах имеется только один скрипт. И такая хитрость может использоваться лишь при удобстве разработке, чтобы не создавать несколько отдельных проектов, и вот тут в примерах.

ScriptActivity.cs

Основной файл скрипта. Тут описывается класс 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. По сути в нем нет смысла, можно и без него.