В предыдущей статье мы говорили о том, как с использованием клиент/серверных технологий можно без труда реализовать простейшее web-приложение с тем, чтобы интегрировать его с NAV’ом. Собственно, последнее действие мы и будем реализовывать прямо сейчас…
Для начала, напишем простейший Codeunit и опубликуем его в качестве web-сервиса:
Поговорим немного о возможностях тестирования в NAV 2009 SP1 и сравнении этих возможностей с тем, что мы имеем сейчас…
Известно, что в как более старых версиях, так и в версии 5.0, достаточно просто заниматься процессом «тестирования»: попробовал сам в ручном режиме несколько сценариев, отдал пользователю пресловутую форму с кнопками и ждешь, когда же он сообщит о найденных на ней ошибках. Понятно, что здесь я немного утрирую, но суть примерно такая, согласитесь?
Собственно, это даже не testing как таковой, поскольку процесс тестирования довольно многогранен:
Все-таки разработка в NAV – прикладная, поэтому нанимать в штат профессионального тестера для выполнения перечисленных вещей выглядит довольно абсурдно…
Вообще, на мой взгляд, тестирование в Навижине – это и не тестирование вовсе. Это – верификация. Т.е. мы проверяем алгоритмы на основании опытных данных, доказывая этим, что ошибки и дефекты отсутствуют с нашей точки зрения (с точки зрения изменяемых и предлагаемых нами методов решения проблемы). Но гарантировать отсутствие дефектов с учетом человеческого фактора (пользователя) не представляется возможным…
И все бы ничего, если бы не одно «Но», о котором я уже написал: конечный пользователь. Человек – не машина и предвидеть какие-то специфичные ошибки/слабости системы, подчас, не в состоянии.
В данной статье хотелось бы привести простейший, но от этого не менее полезный пример того, как можно применить Add-in в NAV 2009 SP1. Что это такое Add-in’ы и как они помогают расширить функциональность RTC-клиента, говорилось в 9-м выпуске Журнала.
Немного предыстории…
В NAV 5.0 появился достаточно интересный инструмент, называемый «Application Worksheet» - «Журнал Применения».
Основное назначение данной формы заключается в том, чтобы предоставить пользователю единый интерфейс, используя который, он может осуществлять ручное применение/расприменение учтенных покупочных/продажных операций.
Как известно, NAV 2009 SP1 обладает рядом свойств и качеств, которые разительно отличают новую версию от ее предшественников. К таковым плюсам, безусловно, можно отнести:
Автор данной статьи не видит необходимости в больших подробностях излагать теоретические выкладки по каждому из приведенных пунктов. Почему? Во-первых, огромное море информации по Web Services можно отыскать в Паутине. Во-вторых, основам технологии создания Add-in’ов для NAV был посвящен весь предыдущий выпуск Журнала. В-третьих, хотелось бы вынести теорию в отдельную большую статью, коррелируя это на NAV. Но это все потом…
Итак!
В предыдущей статье данного номера мы говорили о такой достаточно удобной вещи, как автоматическая коррекция себестоимости, осуществляемая посредством запуска Windows Service, которая, обращаясь к Web Service, вызывает процедуру коррекции в Навижине. После окончания работы коррекции себестоимости, служба Windows автоматически останавливается. Помимо прочего, параллельно записывается лог системного журнала. При желании, можно прикрутить шедулер и служба будет запускаться в любое удобное для Вас время.
В данной статье мне хотелось бы попробовать применить такую замечательную технологию как WWF (Windows Workflow Foundation). Почти как «Всемирный фонд дикой природы» (World Wide Fund for Nature)…
Описывать детально теорию большого желания нет, ибо в Паутине есть все, а ничего нового я не напишу. Так что, всем тем, кто не знаком с базовыми принципами Windows Workflow Foundation, рекомендую обратиться к соответствующим источникам информации. Тем более, что описываемый пример будет достаточно примитивен и доступен для понимания всем желающим.
Итак, вкратце.
Копирование и перепечатка материалов только по согласованию с редакцией.
|
NAV4U (онлайн-журнал) работает на
WordPress.
Локализация maxsite.org
|
|
