|
Владимир Ситников
|
|
15 января 2017 02:31
|
|
Все знают чему равен один ремонт, и там даты покупок привязаны к датам и этапам работ.
В таком случае, держать эти даты в уме тяжело, а в ДД "отчёт по планируемым покупкам" отображается плоским списком, и сложно увидеть-представить это визуально.
Разумеется, я не предлагаю делать из ДД msproject и подобное.
Скорее, было бы хорошо уметь передавать данные из инструмента планирования в ДД.
Собственно, вопрос: на эту тему уже есть что-нибудь?
Я нашёл более-менее удобный (и бесплатный!) инструмент: https://gantter.com/
Работает в web. Сохранять можно как в облаке, так и просто в файлах.
Там есть механизм дополнений, т.е. теоретически можно сделать плагин, чтобы по специальному пункту в меню данные передавались на синхронизацию.
В комментариях к задачам пишем что-нибудь "ДД, счёт:кошелёк", а механизм находит нужные задачи, и актуализирует планируемые операции в ДД.
Т.е. поправили сроки -- оно и поправило сроки плановых расходов.
|
|
|
|
Admin
|
|
16 января 2017 12:22
|
Владимир Ситников Пишет: Собственно, вопрос: на эту тему уже есть что-нибудь? Добрый день.
Можно сказать, что нет.
Точнее - есть API, который для этой цели теоретически подходит, в котором нет поддержки планируемых операций.
Но если кому-то очень сильно потребуется, можем такую поддержку добавить, после реализации прототипа.
|
|
|
|
Владимир Ситников
|
|
16 января 2017 13:05
|
|
>после реализации прототипа.
На вашей стороне?
> есть API, в котором нет поддержки планируемых операций.
Вроде, мобильные приложения тоже хотят?
Ещё хорошо бы добавить "критерий завершения повторений" в эти самые планируемые операции (не для этого конкретного вопроса про gannt, а в целом)
> теоретически подходит
Если будут планируемые, то, вроде, да.
Разумеется, рисовать gantt chart на каждый чих вряд ли стоит. Но для случаев типа "ремонт" по-моему, удобно.
|
|
|
|
Admin
|
|
16 января 2017 15:00
|
Владимир Ситников Пишет: На вашей стороне? Нет, кто будет использовать API.
|
|
|
|
Владимир Ситников
|
|
16 января 2017 15:02
|
|
А что подразумевается под прототипом тогда?
Создание "реальных операций"?
Потом всё равно же придётся переводить на "API планирования".
Какой смысл тогда в прототипе?
|
|
|
|
Admin
|
|
16 января 2017 15:23
|
Владимир Ситников Пишет: А что подразумевается под прототипом тогда? Нужная пользователю программа, которая вместо планируемых операций будет создавать реальные. Потом просто поменяется вызов с парочкой доп. параметров.
Смысл простой - из сотен идей и хотелок до дела доходят единицы, поэтому бросать всё и кидаться править API нельзя.
|
|
|
|
Владимир Ситников
|
|
16 января 2017 15:29
|
|
Операции прямо в demo аккаунте создавать?
|
|
|
|
Admin
|
|
16 января 2017 15:30
|
|
Для начала да. Потом выдадим свой ключик.
|
|
|
|
Владимир Ситников
|
|
21 января 2017 17:18
|
|
Ох уж это API, которое всё возвращает данные как map-list-map-list...
Сурово. Можно же было типы сущностей описать в WSDL...
|
|
|
|
Admin
|
|
21 января 2017 20:20
|
В заголовочном элементе SOAP-ENV:Envelope нужно добавить атрибут xmlns:ns2=" http://xml.apache.org/xml-soap", чтобы использовать далее списки в виде ns2:Map.
|
|
|
|
Владимир Ситников
|
|
21 января 2017 21:05
|
|
Это всё, конечно, хорошо, но это же WSDL! Я не хочу вручную XML элементы указывать. Я хочу, чтобы это делала библиотека.
Сейчас получается, что запросы придётся вообще вручную создавать.
Хотя весь смысл (вся сила) WSDL в том, что если в WSDL описаны типы сообщений, то тогда на любом языке используем нормальные типы, а библиотека генерирует XML запрос.
С ДД же получается, что типы объявлены как "anyType". Информативно.
Вот нашёл на StackOverflow 1-в-1 мою проблему: http://stackoverflow.com/questions/21966629/python-and-php-soap-server
Попробую так.
Ох как не хочется вручную создавать эти item/item/item....
|
|
|
|
Владимир Ситников
|
|
21 января 2017 21:12
|
|
Я говорю примерно про такое: http://stackoverflow.com/a/21016564/1261287
MT = client.factory.create('MoneyTransfer')
MT.transferDate = '01/01/01'
MT.debitAccount = '01234567'
MT.creditAccount = '87654321'
Если бы в WSDL были указаны типы для параметров (не просто anyType, а что-то нормальное), то при использовании на стороне клиента оно выглядело бы по-нормальному, и программисту не приходилось бы создавать XML вручную.
|
|
|
|
Владимир Ситников
|
|
21 января 2017 21:25
|
|
Ещё наблюдение: ответы ДД используют ns2, но не определяют этот namespace.
Нехорошо это всё
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ns1:getCurrencyListResponse>
<getCurrencyListReturn SOAP-ENC:arrayType="ns2:Map[3]" xsi:type="SOAP-ENC:Array">
<item xsi:type="ns2:Map">
<item>
|
|
|
|
Владимир Ситников
|
|
21 января 2017 22:52
|
|
И вообще, http://xml.apache.org/xml-soap это какая-то нестандартная дичь.
Можно было сделать
<xs:element name="item" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="title" type="xs:string"/>
<xs:element name="note" type="xs:string" minOccurs="0"/>
<xs:element name="quantity" type="xs:positiveInteger"/>
<xs:element name="price" type="xs:decimal"/>
</xs:sequence>
</xs:complexType>
</xs:element>
?
|
|
|
|
Владимир Ситников
|
|
22 января 2017 01:03
|
|
Кое как удалось передать этот самый Map.
Пробую создать операцию (через API), удалить её (из web), и после этого не получается создать операцию с тем же самым client_id.
Это так задумано? Вроде, в web записи не видно, но через API возвращается старое значение server_id.
Я хотел для упрощения делать так:
1) удаляем все записи из ДД по определённому тэгу
2) запускаем синхронизацию (она создаёт записи)
3) goto 1
Почему после удаления не получается создать запись с этим же ID?
|
|
|
|
Владимир Ситников
|
|
22 января 2017 01:14
|
|
Собственно, проблемный запрос:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:ns3="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://xml.apache.org/xml-soap" xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns2="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ns4="urn:ddengi" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header/>
<ns1:Body>
<ns4:setRecordList>
<apiId xsi:type="ns2:string">demo_api</apiId>
<login xsi:type="ns2:string">demo@example.com</login>
<pass xsi:type="ns2:string">demo</pass>
<list xsi:type="ns3:Array">
<item xsi:type="ns0:Map">
<item>
<key xsi:type="ns2:string">client_id</key>
<value xsi:type="ns2:int">424243</value>
</item>
<item>
<key xsi:type="ns2:string">server_id</key>
<value xsi:type="ns2:int">80943109</value>
</item>
<item>
<key xsi:type="ns2:string">place_id</key>
<value xsi:type="ns2:string">40030</value>
</item>
<item>
<key xsi:type="ns2:string">budget_object_id</key>
<value xsi:type="ns2:string">40024</value>
</item>
<item>
<key xsi:type="ns2:string">currency_id</key>
<value xsi:type="ns2:string">17</value>
</item>
<item>
<key xsi:type="ns2:string">sum</key>
<value xsi:type="ns2:int">42</value>
</item>
<item>
<key xsi:type="ns2:string">operation_date</key>
<value xsi:type="ns2:string">2017-01-21 19:20</value>
</item>
<item>
<key xsi:type="ns2:string">comment</key>
<value xsi:type="ns2:string">[тест] wsdl</value>
</item>
<item>
<key xsi:type="ns2:string">is_duty</key>
<value xsi:type="ns2:boolean">False</value>
</item>
</item>
</list>
</ns4:setRecordList>
</ns1:Body>
</SOAP-ENV:Envelope>
Ответ:
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ns1:setRecordListResponse>
<setRecordListReturn SOAP-ENC:arrayType="ns2:Map[1]" xsi:type="SOAP-ENC:Array">
<item xsi:type="ns2:Map">
<item>
<key xsi:type="xsd:string">server_id</key>
<value xsi:type="xsd:string">80943109</value>
</item>
<item>
<key xsi:type="xsd:string">client_id</key>
<value xsi:type="xsd:int">424243</value>
</item>
<item>
<key xsi:type="xsd:string">status</key>
<value xsi:type="xsd:string">inserted</value>
</item>
</item>
</setRecordListReturn>
</ns1:setRecordListResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
А по факту, запись не создалась. Т.е. статус "inserted", но записи нет.
Это можно починить?
|
|
|
|
Владимир Ситников
|
|
22 января 2017 15:33
|
|
Как вообще предполагается использовать client_id?
У каждого приложения свои client_id? Или весь диапазон int8 общий для всех приложений, работающих с данным логином?
|
|
|
|
Admin
|
|
22 января 2017 16:31
|
Владимир Ситников Пишет: и после этого не получается создать операцию с тем же самым client_id.
Это так задумано? Здравствуйте.
Да. Это сделано для защиты от дублей, когда клиент присылает одну и ту же запись на добавление, по причине сбоя.
Каждая запись на стороне клиента должна иметь уникальный (внутри своей БД) client_id.
|
|
|
|
Владимир Ситников
|
|
22 января 2017 17:09
|
|
>Это сделано для защиты от дублей, когда клиент присылает одну и ту же запись на добавление, по причине сбоя.
А можно как-нибудь "на всегда" удалить запись?
Ну, со спец флагом или ещё как-то.
Собственно, интеграция: http://recordit.co/Nsl0ofMeYi
Она заливает данные в demo аккаунт в 2018'ый год (ну, чтобы сейчас не особо светилось).
Каковы теперь шансы добавить планирование в API?
Вообще, говоря, неудобно, что нет возможности "просто удалить транзакции".
Я, конечно, могу получать server_id и сохранять их как-то в msproject файле, но было бы гораздо проще удалить все записи из ДД и залить их заново.
Более того, если client_id так "навечно" сохраняется в базе ДД, то почему для обновления требуется указывать server_id?
У меня есть статичные client_id. Я бы мог просто использовать их, но нет, мало того, что записи удалить нельзя (ни в web ни в API), так ещё и без знания server_id обновить невозможно.
|
|
|
|
Admin
|
|
22 января 2017 22:43
|
Владимир Ситников Пишет: А можно как-нибудь "на всегда" удалить запись? Запоминаются клиентские id-ы только с последней синхронизации (т.е. из последнего запроса на добавление). Можно сделать запрос на добавление записи с фихтивным client_id, затем добавить повторно требуемые записи, после чего удалить фихтивную.
Шансы на добавление планируемых операций (но не планирования) повысились, будем добавлять.
Надо продумать как это лучше сделать. Подойдут для этого текущие get|setRecordList или лучше завести новые методы, плюс какие параметры и как включать дополнительно для планируемых.
|
|
|
|
Владимир Ситников
|
|
23 января 2017 00:38
|
|
> Надо продумать как это лучше сделать. Подойдут для этого текущие get|setRecordList или лучше завести новые методы, плюс какие параметры и как включать дополнительно для планируемых.
Сама по себе идея "setRecordList" (отправлять много записей за один раз) по-моему, правильная, т.к. иначе большие накладные расходы на коммуникацию.
С другой стороны:
0) Если говорить про getRecordList, то "старые клиенты" не будут готовы получать планируемые сущности. Там запросто возникнет ошибка обработки и т.п. Получается, возврат планируемых можно делать либо в новом методе, либо, если в запросе приложение явно сказало "да, я понимаю в планировании".
1) Я не понимаю как у вас хранятся планируемые операции. Хранится ли только первая? Хранится ли у планируемых две суммы? (та, которая была по плану и та, которая получилась по факту)
Хранится ли у плановых две даты? (та, которая была по плану, и та, когда внесли)
Или факт "планируемости" хранится вообще в отдельных сущностях?
2) Допустим, у плановых операций появится возможность указать "дату завершения". С точки зрения UI появится как сама возможность "ограничить повторения", так и более интересные "изменить сумму начиная с такого-то повторения" (при этом система должна будет прекратить повторение со старой суммой и тут же создать новую серию с новой суммой).
Вроде, это никак не обязывает выносить "настройку повторяемости" в отдельную сущность, но подобное гораздо логичнее будет выглядеть в своём <planning> тэге (ну или в своём map-list-map), чем в параметрах plan_start_date, plan_end_date, plan_repeat, plan_bla_bla.
3) Непонятно насколько вы готовы вместо map-array-map-array описать типы в WSDL.
Там, вроде, несложно, и при этом автоматически решатся проблемы типа "если это перемещение, то нужны эти поля, а эти означают то-то и то-то".
Грубо говоря, если в запросах будет ходить xsd:type="dd:debit", xsd:type="dd:credit", xsd:type="dd:transfer" (ну или что там), то работать с этим будет проще.
Если добавлять типы в WSDL, то, старые API менять нельзя, а нужно просто добавить рядом новое.
4) А где хранятся лимиты, будь они неладны? Надеюсь, вообще сбоку и их в getRecordList обсуждать не будем?
Но это всё, возможно, лирика.
Основной вопрос какая именно семантика у этого метода setRecordList. Вот был расход. А мы хрясь, и посылаем setRecordList, где указываем, что это доход. Сервер всё поправит "как нужно"?
Т.е. считается, что setRecordList всегда обновляет состояние сущности в соответствии с присланным? Например: был планируемый расход, приложение пытается обновить сущность через API (скорректировать сумму) и при этом "забывает" послать информацию о планировании. Сервер сделает из планируемого расхода фактический?
Возможно, стоит добавить ещё одну версию API, чтобы у старых работало по-старому, а новые клиенты переезжали на новую версию API. Через какое-то время старое API можно будет грохнуть.
|
|
|
|
Инна
|
|
23 января 2017 19:55
|
|
Здравствуйте! Пользуюсь Вашей программой недавно - чуть меньше месяца. Сегодня в настройках я поставила галочку в графе "запрашивать пароль при каждом открытии программы" для личной безопасности. Теперь при открытии приложение просит пароль но перед тем просит синхронизировать. .. а у меня не оплачен сервис и временно нет на это денег, но приложение очень нравится!!! ))) скажите пожалуйста что я могу сделать в этой ситуации?
|
|
|
|
Admin
|
|
23 января 2017 20:06
|
Инна Пишет: что я могу сделать в этой ситуации? Здравствуйте.
Ответили вам в почту.
|
|
|
|
Владимир Ситников
|
|
8 февраля 2017 17:04
|
Сделал обновление данных в ДД через выполнение POST запросов https://www.drebedengi.ru...ivate
Всё бы ничего, но этот URL в ответ выдаёт простыню HTML кода и тратит 0.3-0.4сек на выполнение. Я смотрел другие (те, которые в плане бюджета, те которые в отчётах), но они всё равно формируют огромный ответ.
Можно каким-нибудь параметром сказать ему "не нужен мне html ответ, просто обнови данные и всего делов"?
И вам нагрузка на сервер меньше будет, и у меня быстрее работать станет.
Сейчас загрузка проекта из gantter.com в drebedengi.ru занимает 20 секунд (в проекте ~45 задач).
|
|
|
|
Admin
|
|
8 февраля 2017 18:09
|
|
Попробуйте передать параметр noResponse=1.
|
|
|
|
Admin
|
|
8 февраля 2017 18:20
|
|
Это для планируемых операций, для обычных не сработает.
|
|
|
|
Владимир Ситников
|
|
8 февраля 2017 18:32
|
|
Я, вроде, все как планируемые заношу, но не срабатывает. В ответ приходит 274 килобайта.
Примерно такие данные передаю на ?module=v2_homeBuhPrivate&w_cl_date=...&client_tz=0
{'w_comment': 'comment here {32;1484414955} [auto]', 'action': 'waste_post', 'w_pln_period': 0, 'w_days_before': '', 'noresponse': '1', 'w_date_edit': '08:00:00 15.03.2017', 'w_sum': 3200, 'all_date': '2017-02-08', 'no_response': '1', 'id': '156511', 'waste_id': '156511', 'w_currency': 1469857L, 'is_today': 'true', 'w_future_type': 'plan', 'noResponse': '1', 'w_is_remind': 'false', 'edit_ftype': 'plan', 'w_from': 11989315L, 'pln_edit_remember': '3:false', 'w_category': 12003206L, 'w_duty_person': '', 'w_period_n': '', 'all_date_m': '', 'all_date_h': ''}
Ещё разок сравнюсь, конечно, но, вроде, всё то же самое, что передаёт кнопка "редактировать" в браузере.
|
|
|
|
Admin
|
|
8 февраля 2017 18:47
|
|
Нет, увы, не получится.
Насколько часто и в каком объёме такие запросы будут приходить?
|
|
|
|
Владимир Ситников
|
|
8 февраля 2017 18:59
|
|
На текущий момент план построен где-то до мая. Операции только ручные, т.е. никаких фоновых автоматических синхронизаций нет и не нужно.
В идеальном случае строители не будут переносить сроки, и, соответственно, я не буду обновлять данные.
Но в момент "переноса сроков" нужна ручная корректировка плана (поставили даты, посмотрели как получилось) и, соответственно, синхронизация. Одна синхронизация это где-то 50 запросов. Одного раза иногда мало, т.к. окажется, что даты нужно немного сдвинуть или ещё что.
Т.е. я бы оценил пиковую нагрузку как 5-10 раз по 50 запросов в день. Вроде, немного, но, если есть что-то типа noResponse, то это бы мне упростило работу.
С точки зрения трафика это 300Кб/страница * 50 страниц * 5 / 1024 = 73 мегабайта, вроде, немного.
Нагрузка небольшая (по моим меркам), но есть момент: у google app engine есть ограничение "60 секунд на работу скрипта". Сейчас, конечно, "всего 20 секунд", но не хочется упереться в эти 60 на ровном месте.
|
|
|
Секунду ...
