Skip to content
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

feat: Added ODP RestApi interface for sending Events to ODP #485

Merged
merged 8 commits into from
Aug 29, 2022

Conversation

zashraf1985
Copy link
Contributor

Summary

This module provides an internal service for ODP event REST api access.

Test plan

  • Manually tested thoroughly.
  • Added new unit tests.
  • All Existing Unit tests pass.
  • All existing Full stack compatibility tests pass.

Jira

OASIS-8387

Copy link
Contributor

@jaeopt jaeopt left a 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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private Map<String, String> data;
private Map<String, Object> data;

It can support any type of data (String, Number, Boolean).

Copy link
Contributor Author

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() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public Map<String, String> getData() {
public Map<String, Object> getData() {

Copy link
Contributor Author

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) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public void setData(Map<String, String> data) {
public void setData(Map<String, Object> data) {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment on lines +33 to +36
case GSON_CONFIG_PARSER:
jsonSerializer = new GsonSerializer();
break;
case JACKSON_CONFIG_PARSER:
Copy link
Contributor

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.

Copy link
Contributor Author

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

Copy link
Contributor

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}.

Comment on lines 39 to 44
@Test
public void getCorrectSerializerWhenValidDefaultIsProvided() {
PropertyUtils.set("default_parser", "JSON_CONFIG_PARSER");
assertEquals(JsonSerializer.class, ODPJsonSerializerFactory.getSerializer().getClass());
}

Copy link
Contributor

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.

Copy link
Contributor Author

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\"}}]";
Copy link
Contributor

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>?

Copy link
Contributor Author

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) {
Copy link
Contributor

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.

Copy link
Contributor Author

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) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Comment on lines 20 to 24
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);
}
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

@jaeopt jaeopt Aug 25, 2022

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@jaeopt jaeopt left a 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);
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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 :)

Copy link
Contributor

@jaeopt jaeopt Aug 26, 2022

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;
Copy link
Contributor

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?

@zashraf1985 zashraf1985 removed their assignment Aug 26, 2022
Copy link
Contributor

@jaeopt jaeopt left a 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;
Copy link
Contributor

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?

Copy link
Contributor Author

@zashraf1985 zashraf1985 Aug 26, 2022

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.

  1. null means there was a non recoverable error and no retry is needed.
  2. 0 means an unexpected error and you should retry
  3. Any other status can be handled as needed but my idea is to retry on 500+

@zashraf1985 zashraf1985 removed their assignment Aug 26, 2022
Copy link
Contributor

@jaeopt jaeopt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@zashraf1985 zashraf1985 merged commit 8b8a983 into master Aug 29, 2022
@zashraf1985 zashraf1985 deleted the zeeshan/ats-rest-api-manager branch August 29, 2022 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants