-
Notifications
You must be signed in to change notification settings - Fork 32
feat: Added ODP RestApi interface for sending Events to ODP #485
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. A couple of changes suggested.
private String type; | ||
private String action; | ||
private Map<String, String > identifiers; | ||
private Map<String, String> data; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
private Map<String, String> data; | |
private Map<String, Object> data; |
It can support any type of data (String, Number, Boolean).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
this.identifiers = identifiers; | ||
} | ||
|
||
public Map<String, String> getData() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public Map<String, String> getData() { | |
public Map<String, Object> getData() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
return data; | ||
} | ||
|
||
public void setData(Map<String, String> data) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public void setData(Map<String, String> data) { | |
public void setData(Map<String, Object> data) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
case GSON_CONFIG_PARSER: | ||
jsonSerializer = new GsonSerializer(); | ||
break; | ||
case JACKSON_CONFIG_PARSER: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we see another set of repeated multi JSON parsers. Let's refactor them all for sharing later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Its using the same JsonParserProvider to find out the default one. Its just exporting the implementation class separately. This is separate because it is a seralizer. I wanted to keep parser and serializers separate to avoid confusion. any more parsing or serialization done for ODP will go in to these same classes as added methods. Let me know what you think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Separating parser and serializer looks good. I was talking about the future refactoring discussed already to reuse them in {datafile parser, event serializer, segments parser, and odp event serializer}.
@Test | ||
public void getCorrectSerializerWhenValidDefaultIsProvided() { | ||
PropertyUtils.set("default_parser", "JSON_CONFIG_PARSER"); | ||
assertEquals(JsonSerializer.class, ODPJsonSerializerFactory.getSerializer().getClass()); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add other parsers too to avoid wrong mapping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
|
||
ObjectMapper mapper = new ObjectMapper(); | ||
|
||
String expectedResult = "[{\"type\":\"type-1\",\"action\":\"action-1\",\"identifiers\":{\"vuid-1-3\":\"fs-1-3\",\"vuid-1-1\":\"fs-1-1\",\"vuid-1-2\":\"fs-1-2\"},\"data\":{\"source\":\"java-sdk\",\"data-1\":\"data-value-1\"}},{\"type\":\"type-2\",\"action\":\"action-2\",\"identifiers\":{\"vuid-2-3\":\"fs-2-3\",\"vuid-2-2\":\"fs-2-2\",\"vuid-2-1\":\"fs-2-1\"},\"data\":{\"source\":\"java-sdk\",\"data-1\":\"data-value-2\"}},{\"type\":\"type-3\",\"action\":\"action-3\",\"identifiers\":{\"vuid-3-3\":\"fs-3-3\",\"vuid-3-2\":\"fs-3-2\",\"vuid-3-1\":\"fs-3-1\"},\"data\":{\"source\":\"java-sdk\",\"data-1\":\"data-value-3\"}}]"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change "data" samples to <String: Any> instead of <String: String>?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
return; | ||
} | ||
|
||
if (response.getStatusLine().getStatusCode() >= 400) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Failures with recoverable errors (status=5xx, connection errors, etc) should be differentiated so that OdpEventManager can retry them later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now returning status code from the method so that consuming code can use it and retry when needed.
private Map<String, String > identifiers; | ||
private Map<String, String> data; | ||
|
||
public ODPEvent(String type, String action, Map<String, String> identifiers, Map<String, String> data) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public ODPEvent(String type, String action, Map<String, String> identifiers, Map<String, String> data) { | |
public ODPEvent(String type, String action, Map<String, String> identifiers, Map<String, Object> data) { |
It can support any type of data (String, Number, Boolean).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
public interface ODPApiManager { | ||
String fetchQualifiedSegments(String apiKey, String apiEndpoint, String userKey, String userValue, List<String> segmentsToCheck); | ||
|
||
void sendEvents(String apiKey, String apiEndpoint, List<ODPEvent> events); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like you plan to open these to public (and Android-SDK) to customize. If so, ODPEvent should be open too, but this is not desired. Let's discuss more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any methods that make any external http calls have to be passed in from outside so that we can provide separate implementations for java and android. For java sdk only, the core part is in the core-api
and the http implementation has to be in core-httpclient-impl
. For Android, we will re use all the ODP code int he core-api
but write a new ODPApiManager
implementation and pass from outside. This is why it's open. Let me know what you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zashraf1985 I fully understand opening is required to support Android and other clients. My question was about opening "ODPEvent" type. We can consider to accept serialized String or map instead here, that's how we avoid internal type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would emphasize on keeping the ODPEvent type exposed here. It's only and Entity class which does not contain any business logic. Adding a string input here will increase the burden of unnecessary serialization on us. Keeping it a list of ODPEvent is easy to use and less error prone. What do you suggest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zashraf1985 I understand that it'll look nice to pass the structure, but opening ODPEvent may be expensive. Following our rule, we should rename it to "OptimizelyOdpEvent" like other public type, which also should be documented. Other SDKs also should be changed for consistency. A question is that it's worth to open it for the cost? Clients do not care about the contents, just serialized and dispatched.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you are right. The only responsibility of the httpclient
should be to take the payload, send it and return status. The serialization should be handled in EventManager. I will change it to get the string payload. The serialization code is still useful for the ODPEventManager so i will leave it there with this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of more suggestions.
data.put("data-num", Integer.parseInt(index)); | ||
data.put("data-float", 2.33); | ||
data.put("data-bool-true", true); | ||
data.put("data-bool-false", false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's add to this test, which is also supported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not get this suggestion. Can you elaborate a bit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Let's add to this test". I missed the key word in my comment :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should not use "<null>", which is removed by github :) I meant to add a type checking for "null" type.
@@ -206,17 +205,19 @@ public void sendEvents(String apiKey, String apiEndpoint, List<ODPEvent> events) | |||
response = httpClient.execute(request); | |||
} catch (IOException e) { | |||
logger.error("Error retrieving response from event request", e); | |||
return; | |||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we retry on "null" response? How can we differentiate connection error (retry) from other permanent errors?
…e top level functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my other clarifications in the previous reviews.
@@ -205,7 +205,7 @@ public Integer sendEvents(String apiKey, String apiEndpoint, List<ODPEvent> even | |||
response = httpClient.execute(request); | |||
} catch (IOException e) { | |||
logger.error("Error retrieving response from event request", e); | |||
return null; | |||
return 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either null or 0 is fine with me. My question was that how we can tell if this failure should be retried or not at the upper level. Do you plan to retry all status of 0 and 50x?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes! I will document it on the method too.
- null means there was a non recoverable error and no retry is needed.
- 0 means an unexpected error and you should retry
- Any other status can be handled as needed but my idea is to retry on 500+
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Summary
This module provides an internal service for ODP event REST api access.
Test plan
Jira
OASIS-8387