|
SSRS и рассылка по e-mail
|
|||
---|---|---|---|
#18+
Имеется SSRS отчет квитанции на коммунальные услуги. Ну как положено, входящее и исходящее сальдо, начисления, детализация по перерасчетам, показаниям индивидуальных и общедомовых приборов учета и т.п. В процессе оптимизации пришел к тому, что весь отчет сделал на одной таблице (Matrix), а источником данных стала хранимая процедура. А вот тут я столкнулся с диллемой. С одной стороны, для того чтобы формировать эти квитанции быстрее, чем их печатает потоковый принтер, хранимая процедура была оптимизирована под формирование десятков тысяч квитанций при одном запуске (менее 40 миллисекунд на квитанцию). Скорость формирования отдельно одной квитанции при этом стала около 1 секунды. Для потокового принтера все стало хорошо. А вот для рассылки одиночных квитанций по электронной почте - все плохо. Соответственно, размышляю над следующими вариантами: 1. Каким-то образом сделать вариант, оптимизированный под одну квитанцию. Тогда можно будет рассылать средствами SSRS по подписке управляемой данными. 2. Сохранять результат в PDF вместе с какой-то скрытой информацией (e-mail адрес, тема, тело письма) и затем какой-то самописной утилитой разбивать этот PDF из десяти тысяч квитанций на десять тысяч файлов, которые уже отправлять по e-mail. Сталкивался кто с такой задачей? Какие еще возможны пути ее решения? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.12.2017, 20:45 |
|
SSRS и рассылка по e-mail
|
|||
---|---|---|---|
#18+
неочень понятно, что стало плохо разделите 2 задачи и решайте их отдельно исходя Можете пакет в SSIS написать или даже SQL Server через dbmail. Только в черные списки не попадите:) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2017, 08:53 |
|
SSRS и рассылка по e-mail
|
|||
---|---|---|---|
#18+
bbx1389, Плохо то, что по одной квитанции формировать на SSRS ОЧЕНЬ медленно. Даже если довести до 0.5 секунд на квитанцию, написанием отдельной процедуры (что уже не есть хорошо), то тогда даже 100 тыс квитанций я рассылать буду 14 часов, что ни в какие ворота не лезет. И не понятно, при чем тут SSIS? У меня форма квитанции на SSRS со всеми причендалами, QR-кодом и прочей рекламной нечистью. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2017, 11:06 |
|
SSRS и рассылка по e-mail
|
|||
---|---|---|---|
#18+
ptr128, ssrs вам тогда мало чем поможет, если управляемые подписки негодны... проблема в скорости рендеринга или получения данных? попробуйте, как и было сказано разбить на задачи: 1. получение данных (всех), 2. используя локальный процессинг ReportViewer контрола подпихивайте данные и рендерите в отдельные pdf. 3. полученное добро шлите на почту. P.S.: не знаю... как там с многопоточностью при использовании ReportViewer control, но можно попробовать распараллелить 2+3 (можно попробовать SSIS пакет сделать) P.P.S.: а сколько занимает формирование и отсылка почтового сообщения? вас как спамера могут забанить на почтовике :) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2017, 11:49 |
|
SSRS и рассылка по e-mail
|
|||
---|---|---|---|
#18+
buser, У меня не может быть локального процессинга, потому что нет локала. У меня есть только SQL сервер с SQL Server Agent и сервер для SSRS. Задачи и так разделены. Хранимая процедура на SQL формирует в одном выходном потоке неограниченное (в пределах размера tempdb) количество квитанций. 10 тыс. без проблем формируются менее, чем за 400 секунд. Проблема в скорости рендеринга одиночной квитанции. В одном потоке SSRS 10 тыс. квитанций рендерит в PDF за полчаса. Запустив 8 потоков на 4 ядрах я получаю время рендеринга менее, чем 40 мс на квитанцию. Естественно, пока SSRS их рендерит я могу на SQL спокойно готовить очередную порцию в хранимой процедуре. А вот одиночную квитанцию в PDF SSRS, хоть убейся, быстрее чем за 500 мс (0.5 сек) не рендерит. То есть, формируя восемь PDF, каждый из которых содержит 10 тыс квитанций, я трачу 6 минут на хранимую процедуру и 6 минут на рендеринг в восемь потоков на SSRS. А вот если я из этого потока начну редерить по одной квитанции в PDF, то 8 потоков SSRS у меня будут рендерить больше часа, что ни в какие ворота уже не лезет. Ладно, начал уже изучать iTextSharp. Если получится им быстро разбивать один большой PDF на множество мелких, отправляя их аттачами по SMTP, то на том и остановлюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2017, 15:50 |
|
SSRS и рассылка по e-mail
|
|||
---|---|---|---|
#18+
buserP.P.S.: а сколько занимает формирование и отсылка почтового сообщения? вас как спамера могут забанить на почтовике :) Мне это по фигу. Это уже проблема того поставщика коммунальных услуг, который эти квитанции рассылает ) SMTP у него на хорошем сервере стоит. Должен с такими потоками легко справляться. Про время сказать пока ничего не могу, так как exim справляется явно быстрее, чем SSRS ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2017, 16:00 |
|
SSRS и рассылка по e-mail
|
|||
---|---|---|---|
#18+
Короче так. Глаза боятся - руки делают. Тему можно отмечать [SOLVED] За два часа написал утилиту на C#, которая разбивает один огромный PDF с кучей квитанций, на множество мелких, содержащих по одной квитанции и сразу же их отправляет по электронной почте. Теперь подробности. 1. В источнике данных должны быть: - уникальный номер документа - электронный адрес получателя или список получателей, разделенных запятой (все, что допустимо в поле To: e-mail) - тема сообщения - текст сообщения 2. В SSRS отчете размещаем, например, первой строкой поле с белым шрифтом на белом поле (чтобы видно не было) и размером шрифта в 1 пункт следующего содержимого: - маркер начала поля из четырех символов "&$#!" - уникальный номер документа (только цифры) - разделитель "%" - электронный адрес получателя, закодированный в base64 - разделитель "%" - тема письма, закодированная в base64 - разделитель "%" - тело письма, закодированнное в base64 - маркер конца поля из четырех символов "&$#!" Кодирование в base64 пришлось использовать, так как это оказалось простейшим способом совладать с кириллицей в PDF. У меня это получилось так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42.
Утилита имеет три параметра: 1. адрес или доменное имя SMTP сервера для отправки писем и через двоеточие - номер порта на сервере; если номер порта указан, то отправка писем будет производиться по STARTTLS, а в противном случае - на 25 порт без SSL 2. e-mail отправителя сообщения; 3. путь к PDF файлу За саму утилиту просьба сильно ногами не бить, так как это первый в жизни мой код на C#. Главное - работает ) Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163.
Если e-mail для документа определен, то в начале каждого листа у него наша скрытая строка будет заполнена. Если не определен - строка будет пустая. Если документ занимает несколько листов, то утилита определит это по повторению номера документа на последующих листах. Со скоростью все очень хорошо. Дробит PDF библиотека iTextSharp очень быстро ) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.12.2017, 21:22 |
|
|
start [/forum/topic.php?fid=31&tid=1533019]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 139ms |
0 / 0 |