Lotus Domino, Частина 1: Не такий як усі. Роль і місце. (Електронна книга), Інтеграція додатків і даних, Бази даних, статті

Що таке Lotus Domino, священне чудовисько про який ніхто нічого толком не знає, крім того що воно живе в своєму власному світі в якому панують малозрозумілі звичайним смертним закони і спілкуватися на рівних з яким може тільки вузька каста жерців? Або це відкрита гнучка і дуже зручна для користувачів і розробників сучасна система управління бізнесом.


Передмова


В даний час склалася ситуація коли багато фахівців в області ІТ (практично всіх адміністративних рівнів), навіть ті хто орієнтований на рішення IBM мають дуже не чітке уявлення про те що стоїть за таким брендом як Lotus. Звичайне уявлення полягає в тому, що це чи система електронної пошти, або якийсь "напівфабрикат" документообігу. І коли дізнаються «весь список» можливостей системи Lotus Domino, то звичайною реакцією буває крайня ступінь здивування. Причина такої ситуації в нашій країні в принципі зрозуміла і полягає вона у відсутності «інформаційного шляху» до цього продукту. Не можна сказати, що б літератури з Lotus Domino немає зовсім, але те, що можна знайти на полицях дуже не багатьох великих магазинів, це обмежений набір жахливо, для не підготовленого читача, товстих і досить дорогих видань, розрахованих або на фахівців, або на тих, хто вже все для себе вирішив і тепер готовий освоювати цей продукт, у що б то не стало. І абсолютно ясно, що ніхто не стане брати таку книгу просто для загального ознайомлення з системою, навіть якщо в цей момент вирішує питання щодо вибору продукту для реалізації будь-якої задачі. А з іншого боку існують матеріали, що мають занадто виражену рекламну забарвлення з життєствердними оповідками про «щасливих володарів». Втім, доходять вони в основному лише до IBM орієнтованих клієнтів. Безумовно, такі матеріали часто мають дуже позитивний вплив на керівних працівників, але вони здебільшого відправляють їх на експертизу технічним фахівцям, а якщо фахівець детально не знайомий з продуктом, і при цьому не зміг знайти потрібну інформацію, то не складно здогадатися, яке закінчення він дасть. Цією статтею я збираюся дати відповідь якраз на ті питання, які не зачіпаються в рекламних матеріалах з одного боку і надійно заховані в товстих томах для фахівців з іншого. Так, наприклад, ніж модель роботи з інформацією в системі Lotus Domino відрізняється від шірокораспространненой реляційної моделі, якими перевагами володіє і яку специфіку має. Що важливо враховувати при виборі базової системи для створення інформаційного середовища, в яких випадках доцільно застосування системи Lotus Domino. Яким чином організовується взаємодія з іншими системами зберігання даних (методичні питання створення "еталонної інформації" у гетерогенних середовищах). Сподіваюся, що ця стаття буде корисна фахівцям, що займаються розробкою і впровадженням інформаційних систем рівня підприємства, і тоді коли стоїть стратегічне питання про вибір продукту і в процесі підтримки та розвитку існуючих додатків. Відразу хочу відзначити, що набору інструментів програмування системи Lotus Domino цілком достатньо для створення додатків відповідають найвищим вимогам сучасних користувачів бізнес систем, що і буде видно з конкретних прикладів. Дані матеріали засновані на досвіді розробки та впровадження систем в області дилерського рітейлу IT продукції, в галузі медичного страхування "ОМС" і галузі постачання в організації, що займається будівництвом мережі кабельного телебачення.


Чи не реляційний!


Так що ж таке система Lotus Domino, що вона вміє і для чого призначена. Важливою особливістю системи Lotus Domino є модель управління даними. В даний час ми настільки звикли до табличної формою подання інформації, що у багатьох давно склався стереотип первинності, навіть можна сказати фундаментальності, реляційної моделі (інформаційного) світу. Так от, ні по організації даних, не за коштами підтримки взаємозв'язків між об'єктами, система Lotus Domino абсолютно не реляційна. Ймовірно найбільш точне визначення її може звучати як документарна. Легко уявити собі цю систему на прикладі роботи з звичайними паперовими документами. В реальному світі існує величезна кількість форм документів, відразу звернемо увагу на ці терміни – ФОРМА і ДОКУМЕНТ, до них ми скоро повернемося. Для розгляду візьмемо, наприклад такий документ як платіжне доручення, цілком звичайний в бухгалтерській роботі. Відволічемося від загальної інформатизації і уявімо, що даний документ заповнюється від руки. Як відбувається робота з цим документом за такою технологією. Процес очевидний, бухгалтер бере бланк і починає заповнювати поля, для цього він використовує різні довідники (наприклад з даними про банках БИК, кор. рахунок тощо) та документи на підставі яких буде проводиться платіж (рахунок, договір і т.п.), після заповнення документ підписується відповідальними особами і передається в банк, де в нього заносяться відповідні дані про виконання платежу, після чого цей документ підшивається до відповідної папку де і зберігається встановлений законом термін. У цей період дані з цього документа можуть бути використані для створення інших документів, наприклад періодичних звітів у вигляді балансів і т.п. Як ми всі знаємо цей процес повторюється багато разів і документи в досить великих обсягах накопичуються в архівних папках. Тепер уявімо собі ситуацію, коли контролюючі структури вирішили, що дані в документі вже не відповідають вимогам поточного моменту або просто форма не дуже зручна для роботи і вирішують змінити форму бланка документа, а заодно додати пару нових полів і викинути яке-небудь не потрібне. Видається нормативний документ наказує з певного моменту працювати по новому. Готуються інструкції описують правила і порядок роботи з новою формою, формуються нові або корегуються існуючі довідники. Що при цьому відбувається в циклі роботи з документами, вообщем то нічого особливого, просто з встановленого періоду службовці беруть бланки нового зразка, відкривають нові або скориговані довідники і заповнюють документ відповідно з новими інструкціями. У кінцевому підсумку в архівні папки надходять документи, що відрізняються як по вигляду, так і за змістом від тих, що там вже зберігаються. А тепер зовсім дурний з точки зору реального документообігу, але досить важливий для розуміння документарній природи даних питання, що станеться з документами, які були зроблені і знаходилися в обігу до моменту прийняття нових нормативних актів після вступу нових змін в силу? Зовсім нічого! У полях бланків залишаться ті ж дані, навіть якщо в довідниках звідки вони були взяті формат їх змінився і навіть у тому випадку якщо вони і зовсім від туди зникли. Очевидно, що навіть якщо й самі довідники будуть скасовані, то і ця подія ніяк не вплине на зміст полів уже заповнених документів. Відсутність постійної взаємозв'язку між об'єктом куди поміщаються і де зберігаються дані з еталонним джерелом цих даних слід відзначити як одну з важливих особливостей документарній моделі. Але відсутність властивості підтримки посилальної цілісності це всього лише важливе спадкування з області реальних документів, що робить систему зручною для створення документоорієнтованих процесів. При цьому слід зазначити, що ця властивість, дуже важливе і корисне в багатьох випадках, досить часто не розглядають як важливий критерій у визначенні системи як реляційної. Більш важливим критерієм у цьому питанні вважається спосіб організації зберігання інформації.





 


Життя без таблиць


Тепер давайте подивимося, що і як зберігає система Lotus Domino. І знову ми бачимо принципову відмінність від більшості систем управління даними. Якщо ми подивимося на більшість систем зберігання та управління даними, починаючи від найскладніших програмних комплексів типу IBM DB2, MS SQL Server, Oracle і до доступного практично всім MS Exel, то побачимо, що організація даних у них має чітко структуровану форму, і всі вони засновані на табличній організації. Одиницею зберігання в таких системах є, то що найчастіше називають "ЗАПИС" або "РЯДОК", яка складається з колонок які й створюють структуру даних табличного об'єкта. Всі системи засновані на цьому принципі вимагають опису структури даних, а якщо вони ще й реалізують реляційну модель з властивостями підтримки посилальної цілісності, то й опису взаємозв'язків між об'єктами. Такі вимоги часто призводять до того, що внесення змін у вже діючу систему буває надзвичайно складно і потребує великих накладних витрат іноді аж до перенесення даних в іншу, заново створення структури. Коротко можна сказати, що структура даних і опис взаємозв'язків є основою таких систем. Тепер, щоб краще зрозуміти, як організовано зберігання даних у системі Lotus Domino знову повернемося у світ реального документообігу. Що робить аркуш паперу з нанесеною на нього інформацією документом? Перш за все сама інформація! А не організація її розміщення на аркуші, хоча і це буває важливим моментом. Наприклад, лист паперу стане заявою на відпустку, тобто документом, тільки в тому випадку якщо на ньому буде міститися інформація про те, від кого воно надійшло, кому адресовано, а також дані по суті питання, тобто період, на який даний відпустку проситься. А величина відступів, колір чорнила як правило великого значення не мають, головне щоб почерк був читабельним а текст однозначно інтерпрітіруемим. Та й платіжне доручення завжди буде прийнято до виконання, якщо буде містити всю необхідну інформацію і необхідні атрибути не дивлячись на відмінності в типі і величиною шрифту та інших поліграфічних тонкощах. Таким чином ми приходимо до того, що для того щоб створити документ нам необхідний лише аркуш паперу і інструкція щодо заповнення. Хоча готовий бланк нам безумовно суттєво полегшить роботу. Відповідно і в системі Lotus Domino, в якій ми маємо справу з об'єктами, які носять назву «ДОКУМЕНТ» картина буде аналогічною. Для об'єктів «ДОКУМЕНТ» системи Lotus Domino, так само як і для реальних документів, структура є не самим головним, більше того її можна легко поміняти по ходу справи без будь-яких помітних потрясінь, не кажучи вже про перекручення або втрату даних. Тобто висновок буде такий наявність структури даних бажане, але не обов'язкова умова для роботи в системі Lotus Domino.



Не чекати узгоджень


Можна починати працювати буквально з чистого аркуша або краще сказати на чистому аркуші. Ми можемо створювати документ і заносити в нього інформацію, а потім проводити з цим документом будь-які типові для бази даних маніпуляції, такі як, сортування, угруповання тощо, не маючи уявлення, як цей документ буде в кінцевому підсумку влаштований. Продовжуючи аналогію з аркушем паперу, ми, якщо не знаємо, яка форма документа просто записуємо на нього інформацію в тому вигляді, який знаходимо зручним. У випадку з реальним документом якщо виявиться що для нього існує бланк, нам доведеться переписати його вже на бланк і цілком ймовірно доповнити будь то інформації про вимогу, на яку і не здогадувалися, а можливо, щось у нашому чорновому документі виявиться зайвим. Аналогічна схема працює і в системі Lotus Domino, але тільки на відміну від паперового документообігу працю з перенесення даних на бланк вона візьме на себе, причому бланків цих може бути будь-яка кількість, а наявність зайвої або відсутність необхідної інформації не зупинить роботу. У реальному житті це означає, що в системі Lotus Domino можна починати працювати ще до того як будуть вирішені і узгоджені всі питання про те, що і як потрібно збирати, зберігати і обробляти.



Документ і його Форми


Напевно, тепер необхідно домовитися про використання деяких термінів. В будь-якій системі управління даними існує об'єкт, який можна назвати «одиницею зберігання» і який містить в собі ті корисні дані, заради яких власне і використовується дана система. У системах заснованих на табличних структурах, таким елементом є «ЗАПИС», яка, як ми вже говорили, має певну структуру, тобто колонки або поля, структура «ЗАПИСИ» є її обов'язковим і невід'ємним властивістю, причому в кожен конкретний момент часу може існувати тільки одна єдина структура. Я хочу особливо відзначити цей факт і ось чому. В системі Lotus Domino одиницею зберігання є «ДОКУМЕНТ», але в розділі розробки ми не знайдемо жодних явних ознак його існування, виявити «ДОКУМЕНТ» можна тільки в області даних. А коли ми захочемо створити який або документ, то нам запропонують скористатися для цієї мети «ФОРМОЮ», яку ми легко знайдемо в розділі розробки. І коли ми відкриємо вже існуючу або почнемо створювати нову форму, то виявимо, що ми виробляємо структурування, призначаємо поля, визначаємо типи даних, які вони повинні містити, зовсім так само як в табличних системах. Правда, при цьому ми ще маємо можливість розробити дизайн документа, але це можна було б віднести на особливості системи. І складається враження, що ставлення «ДОКУМЕНТ» – «ФОРМА» аналогічно такій властивості «ЗАПИСИ» як структура. Це абсолютно не так! «ДОКУМЕНТ» в системі Lotus Domino це одиниця самовизначення, у всякому разі, для всіх хто не займається розробкою власне системи. «ФОРМА» це об'єкт, за допомогою якого відбувається взаємодія користувача з «ДОКУМЕНТОМ». Досить грубою, але наочною аналогією може послужити персональний комп'ютер, якщо ми системний блок разом з усім його вмістом уявімо, як «ДОКУМЕНТ», а набір периферійного устаткування призначеного для взаємодії з користувачем (клавіатура, монітор, миша, сканер, принтер і т.п.) як «ФОРМУ», то можна легко переконатися в тому, що зміна складу обладнання входить в «ФОРМУ» не дивлячись на всілякі цікаві ефекти безпосередньо ніяк не відіб'ється на даних зберігаються в тому, що ми тут називаємо «ДОКУМЕНТОМ». На інформацію в «ДОКУМЕНТІ» може вплинути тільки користувач використовує «ФОРМУ» як інструментального засобу. І так само як у нашому прикладі ми можемо взаємодіяти з «ДОКУМЕНТОМ» в системі Lotus Domino за допомогою різних «ФОРМ» і зміна «ФОРМИ» не робить впливу на зміст «ДОКУМЕНТА». Якщо повернутися до порівняння з реальним документообігом, то частіше за все нам не важливо як був виготовлений аркуш паперу лежить зараз перед нами, більшість має про це лише саме загальне уявлення, нас більше цікавить питання що буде записано на цьому аркуші і куди він далі піде. Так само і в системі Lotus Domino ми отримуємо «ДОКУМЕНТ» таким, яким його створює система і до того моменту, коли вона надасть його в наше розпорядження ми не владні як-небудь на нього вплинути. На відміну від систем табличного типу, де, перш ніж створити «одиниць зберігання» з нас запитають самі докладні інструкції з цього процесу, а потім запускається конвеєр, перепрограмувати який іноді буває дуже не просто. Якщо знову звернеться до реальних паперів, то можна сказати, що в системах з табличними структурами ми отримуємо для роботи готові бланки з досить суворими правилами заповнення, причому в більшості випадків необхідно при розробці цих бланків максимально врахувати все, що може бути необхідно для роботи. В системі Lotus Domino ми отримуємо в своє розпорядження набір від чистого листа до бланка з досить складною організацією. При цьому інформація, нанесена навіть на «чистий аркуш» все одно буде структурованої і у нас буде можливість працювати з нею саме як зі структурою.



Відсутність структури? або …


Давайте тепер більш уважно розглянемо об'єкт, який в системі Lotus Domino називається «ДОКУМЕНТ». Відразу можна сказати, що як при вивченні реального документа, мало хто добирається до молекулярної структури аркуша паперу і чорнила, ми так само зосередимо свою увагу тільки на те, що становить практичний інтерес. Важливо відзначити такий факт, що коли ми звертаємося до системи Lotus Domino із запитом створити «ДОКУМЕНТ», то ми позбавлені можливості повідомити їй наші «побажання» відносного того, що ми хочемо побачити. При роботі через користувальницький інтерфейс це звичайно не так очевидно, так як там нам необхідно вказати «ФОРМУ» за допомогою, якої ми будемо вносити дані, хоча ми тепер вже знаємо, що відносини «ДОКУМЕНТА» і «ФОРМИ» можуть бути «швидкоплинними» і всерйоз покладатися на такий «союз» було б необачно. Якщо ми звернемося до засобів програмування системи Lotus Domino, наприклад, до мови LotusScript, то ми зможемо легко переконатися, що у методу CreateDocument об'єкта notesDatabase немає параметрів! Ми не можемо вказати системі, зробити документ на підставі, який або структури. У цьому моменті можна виявити різницю між системою Lotus Domino і реальним документообігом. У реальному житті як ми знаємо, документи оформляються найчастіше на бланках аналогами, яких у системі Lotus Domino є «ФОРМА». Реальний документ створений на бланку вже не може змінити свою форму, все, що ми можемо зробити, це заповнити інший бланк, ймовірно, цим і пояснюється такий достаток паперових форм документів. А в системі Lotus Domino ми легко можемо використовувати будь-яку кількість «ФОРМ» для одного і того ж документа. Система дає нам чистий аркуш (хоча звичайно він містить службові відмітки) і пропонує записати на нього все, що нам потрібно. Звичайно, як і в реальному житті, де ми, якщо хочемо щоб нас зрозуміли, дотримуємося певних правил, наприклад, використовуємо для записів російську мову, слова пишемо в рядки, з ліва на право які маємо зверху вниз, так і в системі Lotus Domino існують правила, яких слід дотримуватися. І пов'язані вони, безумовно, зі способами зберігання інформації. Для зберігання інформації в «ДОКУМЕНТІ» система Lotus Domino використовує об'єкт оригінальну назву, якого – «Item». Очевидно, що його назва перекладається як пункт, але можна назвати його елемент або сутність, важливо, що він є базовим модулем зберігання інформації. Слід звернути увагу на те, що даний об'єкт – саме «Item», так само як «ДОКУМЕНТ» не зустрічається в розділі розробки в явній формі, його визначення можна знайти тільки в програмних кодах, тобто він ніде не визначений статично. Засобом для роботи з цим об'єктом через візуальний інтерфейс служить «ФОРМА». Її об'єкти звані «Fields» якраз і визначають, що і в якому вигляді ми побачимо на екрані монітора, і які дані потраплять в документ після збереження. Я спеціально звертаю на це увагу, щоб підкреслити ще одну особливість системи Lotus Domino, на відміну від більшості систем управління даними об'єкт «Field» в ній не є місцем зберігання даних, а служить інтерфейсом для взаємодії між «Item» в «ДОКУМЕНТІ» і засобами для користувача інтерфейсу. Хоча необхідно відзначити, що «Fields» може зберігати і перетворювати дані і не завжди вміст «Fields» і «Item» до якого він ставиться однаково. Забігаючи вперед, скажу, що це властивість треба обов'язково враховувати при роботі з об'єктами класу «Front-End». Але повернемося до нашого «Документи», щоб занести в нього інформацію, нам необхідно скористатися такими властивостями «Item» як його ім'я і власне вміст, про тип даних можна не турбуватися, система сама визначить його за джерелом. Точно так само можна не хвилюватися і про обсяги, необхідні для зберігання інформації розрахувати їх в системі Lotus Domino можна лише вельми і вельми приблизно, та й то, швидше за все результат буде не вірним. Ну а про способи зберігання я навіть і говорити не буду, бо у програмістів розробляють програми в системі Lotus Domino немає ніяких інструментів для впливу на них. Напевно, може скластися враження, що система Lotus Domino щось безформне піддаються ніякої систематизації, але це не так, просто спосіб організації в ній дещо іншою, ніж ми звикли бачити.



Структура на вимогу


Давайте спробуємо розставити все по поличках. Об'єкт «ДОКУМЕНТ» є контейнером, в який система укладає об'єкти «Item» таким чином, який знайде для себе найбільш зручним. Ми можемо ставитися до «Item» на пряму використовуючи засоби програмування типу мови LotusScript або використовуючи користувальницький інтерфейс посредствам «ФОРМ», «УЯВЛЕНЬ» та інших об'єктів мова про які попереду. Всі ці кошти мають добре опрацьовану організацію. Наприклад, LotusScript є сучасним об'єктно-орієнтованою мовою програмування зі зрозумілою більшості програмістів організацією та набори класів, які в ньому застосовуються, мають чітку добре спроектовану структуру. А візуальний будівник, за допомогою якого готуються об'єкти користувача інтерфейсу, дозволяє створювати зручні і ергономічні елементи. У будь-якому випадку нам наданий повний набір інструментів для роботи з «ДОКУМЕНТАМИ», як з основним об'єктом зберігання організованої інформації, тобто ми можемо організовувати пошук, вибірку, проводити сортування, угруповання і т.п. При цьому ми маємо прямий доступ і безпосередньо до «Item» для запису, читання і редагування інформації в них. І що саме головне ми можемо вносити зміни в структуру, а точніше в те, що ми називаємо тут структурою, не побоюючись за втрату інформації в системі в цілому. І ми підійшли до ще одного важливого для розуміння принципу побудови Lotus Domino фактом, структурування інформації в системі існує, але воно винесено в окремий шар, який може мати одночасно множинні статичні зв'язку з реальними об'єктами, що дозволяє нам використовувати модель «Структура на вимогу».



Роль і місце …


Необхідно відразу відзначити, що ми зараз розглядаємо інформаційні системи як інструментальні засоби для реалізацій рішень ділових завдань, а не проводимо порівняння готових продуктів для кінцевого користувача створених на їх основі. Як ми бачимо різні інформаційні системи, реалізують різні моделі зберігання та управління даними. І будь-яка ця модель, як втім, і будь-яка модель має достатньо жорстку, практично дискретну локалізацію тій області, де застосування її найбільш оптимально. І щоб застосування системи було легким і приємним нам необхідно дуже добре уявляти природу даних, з якими їй належить працювати. В основі будь-якого ділового процесу лежить шлях від бізнес ідеї до реального її втілення і збуту, у вигляді продукту або послуг. І кожен етап цього шляху грунтується на інформаційному обміні. Але як різниться природа даних на різних етапах. Від концепції, через бізнес-план і до технологічних карт і логістичних схем. Практично ми проходимо від області чистого розуму та ідей, до конкретних продуктів і послуг, що знайшли свою реалізацію у праці великого числа людей. Подивимося, що змінюється при русі по цьому шляху. Коли мова йде про концепцію, ми бачимо, що інформація носить в більшою мірою описову форму, багато в чому вона навіть абстрактна. Як правило, вдала бізнес ідея заснована на трьох факторах, по-перше, це потреба (вона ж область збуту), по-друге, ця пропозиція, максимально задовольняє потреби і, по-третє, це спосіб з'єднання потреби з пропозицією (організація збуту). На цьому етапі організувати інформацію в чіткі табличні форми практично не можливо. На наступному етапі, як правило, відбувається з'єднання концепцій та ідей в єдине ціле, зване бізнес планом. При формуванні бізнес-плану, ми починаємо організовувати інформацію, збираються дані необхідні для аналізу можливостей по реалізації ідей, виникають категорії, в яких можуть агрегуватися зібрані дані (наприклад, обсяг ринку збуту, накладні та організаційні витрати, витрати на розробку та просування, виробничі витрати і т.п.). Якщо процес має продовження, то дані починають шикуватися вже в чітко організовані форми. Розробляється виробничий план, план дистрибуції і продажів. Ці документи в більшості випадків мають регламентовану форму та інформація, яку вони містять, добре структурована і має стійкі взаємозв'язки. Ці дані явно наближаються до реляційної області. Ну а при подальшому русі інформація стає ще більш чітко організованою (технологічні карти, нормативи і т.п.). Інший інформаційний потік це взаємодія стратегічного управління, тактичного планування, оперативних рішень і конкретного виконання. Класична управлінська вертикаль. І тут ми бачимо, як змінюється природа інформації при русі від стратегічної концепції (наприклад, підвищення ефективності роботи співробітників), до конкретного виконання (наприклад, плану впровадження нового програмного комплексу та закупівлі нового офісного обладнання). Практично ми бачимо, що чіткої, добре організованої структури можна домогтися тільки при взаємодії з областю рахункових об'єктів. При цьому важливо відзначити, що всі інформаційні потоки, що мають керуюче вплив на об'єкти цієї області мають документарну природу. Очевидно, що застосування системи Lotus Domino для організації документарних потоків більш доречно, ніж використання для цих цілей реляційних систем. У той же час для роботи пов'язаної з організацією планування та розподілу конкретних ресурсів реляційні системи значно зручніше. Хоча використання декількох систем в одній організації і веде до деякого збільшення накладних витрат, але вони в багатьох випадках виявляються значно нижче, ніж сумарні витрати на розробку і підтримку програм, модель даних яких не відповідає області застосування.

Рис. 1. Розподіл типів завдань щодо ступеня «організації» інформації


На рис. 1 показано розподіл типів завдань щодо ступеня «організації» інформації. Таким чином, можна сказати, що застосування системи Lotus Domino оптимально у сфері загального управління, де основний одиницею обміну є документ та інформація, або не має чітко вираженої структури, або структура схильна до періодичних змін. Крім того, в логіку системи Lotus Domino добре лягають завдання пов'язані з потоками ствердно-дозвільних документів.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*