Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Anonymous_User Absent Member.
Absent Member.
1096 views

APT updating SOAP vs OAPI

In certain circumstances, updates made in the GroupWise client to a child instance of a reoccurring posted appointment date are not reflected on the BlackBerry smartphone.

We ran similar tests where instead of changing the date we changed the time, these appointments were updated correctly. We also tested if you "drag and drop" the appointment instead of using the "Post" button to save changes. It seemed that these tests were also successful. We suspect that this inconsistency is either an issue with GroupWise, or the BlackBerry Enterprise Server and GWITEMINFO are reading the property of the posted appointment incorrectly somehow.

Minimum steps to reproduce:

1. Activate a user on BESG 5.0.1 MR5(POA/GWC 8.0.2 HP3)
2. Create a series of posted appointments in GWC and wait for synchronization with device
3. Using the GroupWise client, open one of the child instances
4. Click the calendar icon
5. Select a new date for the appointment(Change from 11/10/2011 to 11/11/2011)
6. Click "Post" to save changes
7. Observe that the posted appointment is not updated on the device.

[GWITEMINFO]
[0] 11/03 13:27:35 11/3/2011 1:28:10 PM - 4EB288DA.NW1DOM1.NW1PO1.100.1766665.1.F5.1 - '0' - Testing a series of post apt from GWC
[0] 11/03 13:27:37 Appointment Last Modified Date: 11/3/2011 1:28:10 PM

[GWITEMINFO]
[0] 11/03 14:59:58 Appointment Start Date: 11/10/2011 4:00:00 PM
[0] 11/03 14:59:58 Appointment End Date: 11/10/2011 5:00:00 PM
[0] 11/03 14:59:58 Appointment Last Modified Date: 11/3/2011 2:26:15 PM

[POA XML]
<gwt:startDate>2011-11-11T20:00:00Z</gwt:startDate>
<gwt:endDate>2011-11-11T21:00:00Z


We can see that in the POA XML logging the startDate and endDate are updateing correctly and that the POA sends ItemModify SOAP Event to the BES. however all BES does is updates the modify time of the apt. When using RIM's GWITEMINFO Tool we can see that the Start Date and End Date are still showing the old dates. Note that GWITEMINFO uses oAPI to connect to GroupWise.

Although we are not looking for support on BES we would like to know why are we seeing a inconsistence between updating a Child Posted Apt using within the properties of the apt vs. just dragging the apt to a new date. We also found that if you leave the date alone and just switch the time of an apt everything works as expected. Does OPAI read different attributes of an item then SOAP does?
Labels (1)
0 Likes
1 Reply
Anonymous_User Absent Member.
Absent Member.

Re: APT updating SOAP vs OAPI

The OAPI reads the same values, but the OAPI is not actively updated. We
only make selective changes to the OAPI (such as crashes). All new
development is only done on the SOAP API.

Preston

>>> On Friday, November 04, 2011 at 5:46 AM,

rim123<rim123@no-mx.forums.novell.com> wrote:

> In certain circumstances, updates made in the GroupWise client to a
> child instance of a reoccurring posted appointment date are not
> reflected on the BlackBerry smartphone.
>
> We ran similar tests where instead of changing the date we changed the
> time, these appointments were updated correctly. We also tested if you
> "drag and drop" the appointment instead of using the "Post" button to
> save changes. It seemed that these tests were also successful. We
> suspect that this inconsistency is either an issue with GroupWise, or
> the BlackBerry Enterprise Server and GWITEMINFO are reading the property
> of the posted appointment incorrectly somehow.
>
> Minimum steps to reproduce:
>
> 1. Activate a user on BESG 5.0.1 MR5(POA/GWC 8.0.2 HP3)
> 2. Create a series of posted appointments in GWC and wait for
> synchronization with device
> 3. Using the GroupWise client, open one of the child instances
> 4. Click the calendar icon
> 5. Select a new date for the appointment(Change from 11/10/2011 to
> 11/11/2011)
> 6. Click "Post" to save changes
> 7. Observe that the posted appointment is not updated on the device.
>
> [GWITEMINFO]
> [0] 11/03 13:27:35 11/3/2011 1:28:10 PM ‑
> 4EB288DA.NW1DOM1.NW1PO1.100.1766665.1.F5.1 ‑ '0' ‑ Testing a series

of
> post apt from GWC
> [0] 11/03 13:27:37 Appointment Last Modified Date: 11/3/2011 1:28:10
> PM
>
> [GWITEMINFO]
> [0] 11/03 14:59:58 Appointment Start Date: 11/10/2011 4:00:00 PM
> [0] 11/03 14:59:58 Appointment End Date: 11/10/2011 5:00:00 PM
> [0] 11/03 14:59:58 Appointment Last Modified Date: 11/3/2011 2:26:15
> PM
>
> [POA XML]
> <gwt:startDate>2011‑11‑11T20:00:00Z</gwt:startDate>
> <gwt:endDate>2011‑11‑11T21:00:00Z
>
>
> We can see that in the POA XML logging the startDate and endDate are
> updateing correctly and that the POA sends ItemModify SOAP Event to the
> BES. however all BES does is updates the modify time of the apt. When
> using RIM's GWITEMINFO Tool we can see that the Start Date and End Date
> are still showing the old dates. Note that GWITEMINFO uses oAPI to
> connect to GroupWise.
>
> Although we are not looking for support on BES we would like to know
> why are we seeing a inconsistence between updating a Child Posted Apt
> using within the properties of the apt vs. just dragging the apt to a
> new date. We also found that if you leave the date alone and just switch
> the time of an apt everything works as expected. Does OPAI read
> different attributes of an item then SOAP does?

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.