Different architecture of SEMDA-2 and SEMDA-3
SEMDA-2 was collecting all data persistently in a local database. When an update of data in RI has failed, next day the local CMS sent the same data and SEMDA tried again. Because of the poor performance of the RI-API it was not possible (and it is still not possible) to send all data of all members every day to RI. In order to solve this problem, SEMDA-2 had an algorithm detecting which data has changed. Only changed data was sent to RI, reducing the amount of exchanged data to an minimum. However detecting changes in a system sitting in the middle of data exchange is not reliable, when data could be modified on both ends in RI and in local CMS independently without notifying SEMDA about such change. The result is, that many club and member data is not in synch with RI today.
SEMDA-3 connects the local CMS directly to RI without intermediate database and thus eliminates this fundamental problem. It makes the data exchange more responsive and reduces the possibility of wrong data. However it requires that the local CMS handles errors which may occur in the RI-API. The local CMS must handle re-sending of requests, when appropriate and deal with situations resulting from failed transactions in RI. SEMDA-3 API implementation eliminates also some problems resulting from concurrent updates in local CMS and in RI. E.g. passing member address, SEMDA retrieves all addresses from RI, compares them to the requested data and propagates the changes to RI considering all additions, deletions or modifications of the data.
SEMDA-3 is asynchronous. I.E. the completion of the request is finished, when the callback / web-hook is invoked. This decouples the local CMS from RI and preserves the GUI responsiveness. However local CMS must execute dependent transaction is sequences. E.g. terminating member in a club and making him member in another club without awaiting the completion of the termination, cannot work and will inevitably create errors.
Critical scenarios
There are four critical cases, which cause a number of subsequent problems in either RI or in the local CMS system.
Member exists in local CMS, but not in RI
This may happen when new member is added, but the error message from RI is ignored. This can be also a leftover from a difference which was not discovered yet and is lasting since a long time.Member exists in RI, but not in local CMS
This will happen when new member is added manually in MyRotary, but not in local CMS. This can be also a leftover from a difference which was not discovered yet and is lasting since a long time.Member is terminated in local CMS, but not in RI
This may happen when member is terminated, but the error message from RI is ignored. This can be also a leftover from a difference which was not discovered yet and is lasting since a long time.Member is terminated in RI, but not in local CMS
This will happen when member is terminated manually in MyRotary, but not in local CMS. This can be also a leftover from a difference which was not discovered yet and is lasting since a long time.
These cases will cause different member count in RI and in the local CMS and this will have financial impact on the clubs. RI counts the club member twice a year on 15. January and on 15. July. By this date RI will send the clubs an invoice for the RI membership fee.
Cases 2. and 4. are mostly result of wrong communication to the clubs. Many people do not have the technical skills and are not able to distinguish between MyRotary and the local CMS. They think of it as of one system. When RI sends their reminder about the necessary data maintenance, the people do action in the wrong system. This problem cannot be solved on technical level.
Where is the master data authority?
From the perspective of the clubs, the local CMS is the master of the data. It usually stores more data then is available in RI. But from the perspective of RI the master is at RI because the Rotarian membership is issued there. This clash cannot be solved on the technical level. From the view point of the API it can be stated that:
The master authority for club data is RI. Clubs must be created and terminated in RI. Only a few club data can be modified via the RI-API.
The master authority for member data is the local CMS. RI membership model and the current API do not allow management of non-members, candidates or guests. Such affiliations are very common in the most local CMS. There is also a demand to store much more data about the individuals in the local CMS in order to manage and run the club efficiently. Generally speaking, RI needs only the exact member count per club. Additional information is optional.
The master authority for officer data is the local CMS. Only the club can define the responsible people.
Typical RI error messages and how to treat them
Error creating new individual - message: 400 “Possible Duplicate Individual - '5490216'”
The individual cannot be created because RI has found a possible duplicate.
You must check who is the individual with the reported ID and compare it with the individual you want to add. Then you see the difference and can decide if it is a duplicate or not. If it is not a duplicate, you need to add the new individual. Then you have to outsmart the RI system.
You must first add an individual under a new artificial or changed name. This will give you a new RI-ID. Then you must change the newly added individual and correct the data to the real values.
The experience shows, that changing just a name e.g. “Gustafsson” => “xxGustafsson” may not be enough. Changing first name, last name and birthday completely is mostly sufficient.
Error creating new individual - message: 412 “Member already exists see individual ID: 5463233”
The individual cannot be created because RI has found a duplicate. You must check who is the individual with the reported ID and compare it with the individual you want to add. Then you see the difference and can decide if it is a duplicate or not. If it is not a duplicate, you need to add the new individual. Then you have to outsmart the RI system. See the treatment of the error “Possible Duplicate Individual“ how to do it.
Error creating new member - message: 400 “Email Address is in use but can not provide details.”
This means the member with this email is in a club which uses another CMS system and you are not allowed to retrieve the data.
Error creating or updating member - message: 400 “Email Address already exists”
Email is a unique identified in RI and cannot be shared with another individual or organization. You will need to find out which individual or club is using this email in RI. It may be an individual or club outside of your CMS system.
Error updating member - message: 400 “Record exists but access denied”
The request is rejected by RI, because the member is marked as deceased in RI. Data of deceased members cannot be retrieved or modified in RI.
Error updating member - message: 401 “Access denied”
The request is rejected by RI, because the member is marked as terminated or as deceased in RI.
Error updating member - message: 403 “Access denied. Your account does not currently have permission to access this resource. Please contact RI to request access or modification privileges."
The request is rejected by RI, because you try to access clubs or members to which you do not have access. Possibly the club does not have configured SEMDA as the vendor in RI.
Error updating member phone number - message: 400 “Phone Number already exists for this individual.”
RI does not allow to use the same phone number for business, mobile, fixed line or fax. All phone numbers must have distinct values. This is not documented in RI-API, but the API behaves this way.
Error updating member phone number - message: 400 “Unspecified error occurred while inserting fax.”
This is an internal RI error that happened once. We are not able to reproduce it.
You cannot do much about it.
Error updating member sponsors - message: 400
You may get various error message like:
Sponsoring Member ID is not active at the time of Member admission date
Sponsor must be a club member at least one day prior to the sponsored member
Member ID and Sponsoring Member ID not in the same club.
An active relationship already exists for the members 5500697 and 5500798.
and others
The RI rules for sponsors do not match the reality in the clubs. Members may have sponsors outside the own club, sponsors who left the club long time ago or have been transferred to another club. The RI rules work fine only for few “standard” cases especially for new members.
We recommend to ignore the RI errors.
Error updating club officers - message: 400 “already one or more relationships during the specified time frame”
The request is rejected by RI, because multiple officers for the same time period are not allowed. There are different rules for setting the officers for the current and next rotary year.
RI does not allow to modify officers in the past years.
RI does not allow to modify officers which are serving today. You can terminate their function for the current year by setting an end-date.
Then you can define an officer for the remaining time period = starting now until the end of the current community year.
For the future years you can add, modify or delete officers only for the whole year.
There is some limit how far in the future you can add officers. Nobody knows this limit. 2029 was working in TEST but not in PROD. We recommend to add officers only for the immediately next community year 2026/2027
All officer functions require a reference to the individual. You need to know the current situation in RI. When modifying officers you must reference the existing officer in RI. Otherwise the request is rejected. To see the current situation in RI use the Semda-Web search https://search.semda.se/ club search > officers.
When membership is terminated, the member must be also terminated as officer.
Error updating club officers - message: 400 “new End Date is not within the current Rotary year”
The request is rejected by RI, because officers period must end with the respective rotary year. Remember that the rotary year 2025 is the starting 1.7.2025 and ending 30.6.2026 and the rotary year 2026 is the starting 1.7.2026 and ending 30.6.2027. See also the rules mentioned in the error “already one or more relationships during the specified time frame”.
Error updating member data - message: 400 “<field> cannot be greater than <x> characters. The submitted value is <y> characters long.”
There are many fields with length restriction. The SEMDA API has the same restrictions as RI-API. Some of the restrictions are very hard and does not reflect the real values.
prefix (academic title) (12 chars)
address line1,2,3 (40 chars)
ZIP code (20 chars)
city (40 chars)
classification (60 chars)
url (weblink) (80 chars)
meetingComment (120 chars)
Our recommendation is to store the full value in your local CMS but pass only the truncated value to SEMDA. This will avoid errors which could prevent update of other fields.
Error updating member data - message: 500 “Transaction (Process ID xxx) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction”
This is an internal RI error. SEMDA will do one retry after 30 seconds when a write-operation to RI returns an error 500 (independently of the specific reason) .
You cannot do much about it.
Error updating member data - message: 500 “An unexpected Error has occured. Try again or report error.”
This is an internal RI error. SEMDA will do one retry after 30 seconds when a write-operation to RI returns an error 500 (independently of the specific reason) .
You cannot do much about it.
Error updating member data - message: 400 “An error occurred while converting memberId to integer: Cannot open database \"US_OneRotaryHub_PRD\" requested by the login. The login failed. Login failed for user 'HQ\\svc_Disuser_PRD'.”
This is an internal RI error. You cannot do much about it. Try to execute the transaction once again later.
Error deleting member affiliation - message: 400 “The UPDATE statement conflicted with the CHECK constraint "CK_co_individual_x_organization". The conflict occurred in database "US_NETFORUM_PRD", table "dbo.co_Individual_x_organization". The statement has been terminated.'.”
This is an internal RI error. You cannot do much about it. Try to execute the transaction once again later.
Error retrieving member data - message: 500 “Internal server error”
This is an internal RI error. Most likely the RI system is running out of some resources. You will get this error quite often on search an get endpoints. As these operations are queries and you need to wait for the callback anyway, you can decide to repeat the query after some time. SEMDA will not retry the operation!
Error updating member data - message: 500 “Check the Error Log for more details: Conversion failed when converting from a character string to uniqueidentifier.'.”
This is an internal RI error. SEMDA will do one retry after 30 seconds when a write-operation to RI returns an error 500 (independently of the specific reason) .
You cannot do much about it.
Error updating member data - message: 400 “An error occurred while making the HTTP request to https://netforum.rotaryintl.org/xwebpartner/secure/netForumXML.asmx. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server”
This is an internal RI error. Try to execute the transaction once again later.
You cannot do much about it.
Error deleting rotaract member affiliation - message: 400 “Invalid Security Credentials.”
This is a very strange RI error. The transaction is successfully completed and the rotaractor is marked as terminated in RI but RI returns an error. For this reason SEMDA will overwrite the 400 error code and return 200 success when these conditions are met:
The endpoint "DELETE /3.0/affiliation/{ClubID}/member/{IndividualID}" is used
AND when the endpoint is consumed with header X-Community = Rotaract
AND the response from RI is code 400 with message "Invalid Security Credentials"
Error in calculation of 30 days period for admission, termination - message: 400 “Termination Date is not in the 30 days time period (30 days before or after current date)”
RI uses the formula current month - 1, e.g. 2026-03-02 is compared with 2026-02-02. Then 2026-02-01 is too late even it is less then 30 days. We recommend to internally set the period of 28 days in the local CMS.