SOAP Request

[urban@abak]

Hello!

We're using zimbra 4.0.3 opensource and are currently working on migrating calendars via SOAP to zimbra 4.0.4. We're doing it this way as there is an issue with missing appointment details when importing over curl as you sure know.

Is there a SOAP request for getting the appointment, without having to put the appointment ID as a parameter?

I've been through all these soap*.txt files but can't seem to find it.

Thanks in advance.

[dkarp]

Originally Posted by urban@abak

We're using zimbra 4.0.3 opensource and are currently working on migrating calendars via SOAP to zimbra 4.0.4.

Just curious -- why not just upgrade?

Originally Posted by urban@abak

Is there a SOAP request for getting the appointment, without having to put the appointment ID as a parameter?

GetApptSummariesRequest might help you find appointments. I'm not sure if SearchRequest works when told to return appointments, but if so it's your best option (query: in:Calendar).

[urban@abak]

well, the last upgrade we did trashed everything. so we had to re-install and collect our documents and stuff by searching all those folders. we were lucky it happend on a testing server, but trying to fix it cost us a whole day and a half. but i guess that's not the issue here.

about the GetApptSummariesRequest... i don't know what that s="RANGE_START_MSECS_GMT" e="RANGE_END_MSECS_GMT" is good for.

the idea was to somehow get all the appointments, read all their id's, then getting all the appointments one by one with getAppointmentRequest and then transfer to the other zimbra with CreateAppointmentRequest.

well, we'll keep working on it. by the way, i'm totally new at SOAP and been working with zimbra for a month now, so don't mind any non-senses - of which you may feel free to inform me, though - please.

[urban@abak]

and another thing:

we have the 4.0.3 open source version on our production server. the problem there is that search doesn't work really well. it's kind of corrupted, search by attachments doesn't work etc. so there really is no other solution but to copy/transfer the existing zimbra content to a fresh copy of zimbra (4.0.4 on our testing server that will then become the production server)

and another:

we also have a portal (running in BD) connected to zimbra and the idea is to create a module that would alllow us to transfer all the accounts with all the content from one server to another...

i'm pretty sure a lot of people who are working with zimbra would be interested in that kind of a solution...

[dkarp]

Originally Posted by urban@abak

we have the 4.0.3 open source version on our production server. the problem there is that search doesn't work really well. it's kind of corrupted, search by attachments doesn't work etc. so there really is no other solution but to copy/transfer the existing zimbra content to a fresh copy of zimbra (4.0.4 on our testing server that will then become the production server)

That's bad, and odd, and rare. Does this apply to all mailboxes, or just one or two users? (Note that you need the licensed Verity bits from the Network Edition to get attachment search to work for PDF, Word, Excel, etc.)

And, of course, you can reindex mailboxes any time you want via the admin console. Migrating servers to recreate indexes is definitely a case of using a sledgehammer to kill a fly -- generally the wrong tool for the job.

[dkarp]

Originally Posted by urban@abak

well, the last upgrade we did trashed everything. so we had to re-install and collect our documents and stuff by searching all those folders. we were lucky it happend on a testing server, but trying to fix it cost us a whole day and a half. but i guess that's not the issue here.

Yeah, it's very very important to make a backup before upgrading. We cannot stress this enough. Every server is different, and despite the fact that nearly everyone has ./install.sh run flawlessly, if something should go wrong you really want to be able to revert to the world as it was.

Originally Posted by urban@abak

about the GetApptSummariesRequest... i don't know what that s="RANGE_START_MSECS_GMT" e="RANGE_END_MSECS_GMT" is good for.

Start time in milliseconds since 1/1/1970 ("the epoch"), end time in milliseconds since 1/1/1970.

Originally Posted by urban@abak

well, we'll keep working on it. by the way, i'm totally new at SOAP

There are command line tools like zmmailbox and programmatic Java tools like the zclient package that will do the SOAP for you. That might be a more efficient use of your time...

[urban@abak]

Originally Posted by dkarp

That's bad, and odd, and rare. Does this apply to all mailboxes, or just one or two users? (Note that you need the licensed Verity bits from the Network Edition to get attachment search to work for PDF, Word, Excel, etc.)

And, of course, you can reindex mailboxes any time you want via the admin console. Migrating servers to recreate indexes is definitely a case of using a sledgehammer to kill a fly -- generally the wrong tool for the job.

don't know about the licensed stuff, should have asked my boss about that. but it did work before as i know. it got somehow corrupted with all the upgrades and stuff.

don't know what you mean by reindexing, though. we have 2 servers running, the one that's corrupted and the testing one. the procedure we'll be trying will be something like:

- backup
- setting up domains and cos on the 2nd server
- creating accounts on the 2nd server
- transfering mail with imapsync
- transfering contacts in the "wiki says it" way
- transfering appointments with the soap tool

if everything above goes well the only problem as we see it is that we'll have to re-synchronize our customers imap clients with zimbra accounts. we are very thankful for any advice about the migration though - if there's any other thing we should be taking care of...

[urban@abak]

Originally Posted by dkarp

Yeah, it's very very important to make a backup before upgrading. We cannot stress this enough. Every server is different, and despite the fact that nearly everyone has ./install.sh run flawlessly, if something should go wrong you really want to be able to revert to the world as it was.

we're running a scheduled daily backup of all our stuff. no need to worry about that.

Originally Posted by dkarp

Start time in milliseconds since 1/1/1970 ("the epoch"), end time in milliseconds since 1/1/1970.

we got that figured. hope we'll test the first transfer today.

thanks!

[urban@abak]

ok. me again.

the thing is as follows:

we managed to get the id's and to transfer the appointments on one account from one server to another. the procedure is sth like this:

1. we get the id's with GetApptSummariesRequest
2. then we get the appointments with GetAppointmentRequest
3. at this point we get the messages with the content from invId parameters with GetMsgRequest
3. then we read stuff/assign the values to the variables, switch the server and so on and then
4. with CreateAppointmentRequest, we write the appointment on the second server

everything works fine. except one thing. the appoinments details are missing. no error, though.

so, i'm thinking two:

1. the details are there somewhere, but are not viewable or
2. this in general is the same procedure as the one via REST URLs and this is somehow connected to bug 11254

then i tried sth else. wrote the appointment on the 2nd server without the content and then tried to modify the appointment with ModifyAppointmentRequest and XML said FAILURE although all the neccessary XML stuff seemed to be there...

at this point my concentration was literally below zero. so i'm asking you to help a bit. it would be kindly appreciated.

[urban@abak]

ok, next...

we manage to transfer the appointments including the content. after the ModifyAppointmentRequest, basically everything is fine. but the problem occurs as this content is only viewable on mouse over. if we click the appointment now to see the content, it's just not there. we also can't edit the appointment. moving these transfered appointments on the calendar doesn't work... also, after we first write the appointment to the 2nd server the location is there, after the ModifyAppointmentRequest it's not. it looks a lot like this request doesn't really modify the appointment, but completly overrides it.

so, i'm thinking:

is any of this really our "fault" or does this go above the transfer/migration problem?

does it possibly have anything to do with the fact that the account on one server is my.name@our_domain.com and testing@our_other_domain.com on the other?

any help, please?