FAQs
Welcome to our FAQ page. We have compiled a list of the most commonly asked questions and their corresponding answers to help you better understand our Football Odds Solution.
Q: Can you explain the reasoning behind sending event names and opportunities in Market messages and corresponding odds in MarketState messages? What happens if a Market message is lost, and how can we retrieve the information about the events and opportunities?
A) We split out market messages and market state messages to reduce the amount of data sent each time there is a price change.
B) We recommend waiting to acknowledge a message consumed from the Kafka topic until after it has been processed / persisted to avoid losing messages. If messages have been acknowledged the topic can be processed from the beginning re-reading all messages (Kafka messages are compacted on the output topics reducing the number of messages to be read) alternatively the latest set of messages can re-pushed for a specific event or competition from the Destination Controller.
Q: How does the Snapshot Wrapper work, and can it be used to retrieve all markets and their current states after a reconnection?
A: The Snapshot Wrapper is no longer required (it will be removed from the next version of the documentation). If the consumer disconnects for a short period of time and then reconnects it can continue from the previous offset to ensure no messages are missed.
Q: In the Output Feed API v1.54, which messages contain objects such as GameState Clock and GameState Period ID, and are they part of the body fixture or another entity?
A: The game state message is built inside the body of a streaming wrapper in a similar way to the CfsFixture, CfsMarket and CfsMarketState messages. A game period is included inside the matchPeriod element and a game period can include a game state clock, a game state period id, general facts, head to head facts and sub periods.
Q: Will data for matches be ordered through a web console or some other means?
A: We enable operators to filter: pre-match, in-play and game state messages in the Destination Controller at all levels of the hierarchy enabling subscription to all matches under a sport, all matches under a competition or even at a granular match-by-match basis.
Q: Can you provide more information about specific sports and their relevant schemes such as GameStateGeneralFacts, GameState Periods etc.?
A: We are working to enhance the documentation with additional game state information and examples – this is currently on our backlog.
Q: Is it possible to obtain overviews of markets for individual sports that we may be interested in integrating into our system?
A: Our team is preparing the latest version of the market list for each sport which is also currently on our backlog.
Q: What is the bootstrap server endpoint for UAT?
A: The bootstrap server endpoint is https://kafka.feeds-uat01.red.ref.eu-west-1.mts.sgdigital.com:19001
Q: Where can I find the SASL_SSL protocol bootstrap URL?
A: please note that SASL_SSL is currently not supported on UAT (Confirm with Openbet if this is now supported or not) – if not yet supported, we can include the next FAQ:
Q: Will SASL_SSL be supported in production?
A: There are plans to add support for SASL_SSL. For now, the currently supported protocol is SASL_PLAINTEXT.
Q: What protocol should I use if SASL_PLAINTEXT doesn't work?
A: SASL_PLAINTEXT is currently the supported protocol. If it doesn't work, it would require further troubleshooting.
Q: What IP address ranges are permitted to connect?
A: The permitted IP ranges would need to be provided by you so that we can whitelist them from our end.
Q: How can I validate connectivity?
A: Use the 'nc' command for Linux or 'tnc' command for Windows Powershell to check connectivity to the server.
Q: What error message is seen when trying to connect to the bootstrap server?
A: An "Unknown error" message is seen indicating a failure to connect to the bootstrap server.
Q: What IPs should I check for outbound traffic if I'm having trouble connecting?
A: Please check with your infrastructure team that the following two IPs addresses are not blocked:
34.253.81.176
34.253.24.109
Q: What should I do if I'm still not getting any response from the server?
A: Please ensure your request passes through your firewall and double-check your connectivity settings. If the issue persists, please reach to customersolution@imgarena.com. Alternatively please detail the issue in the communication channel setup with IMGA and Openbet team for further assistance.
Q: What is the Kafka API and how can it be accessed?
A: The Kafka API is a platform for handling real-time data feeds. It can be accessed using appropriate urls/links/hostnames/client id/secret.
Q: What are the username and password for the Kafka API?
A: The username and the password will be privately sent by IMGA/OpenBet for security purposes.
Q: Are the username and password for destination control the same for the Kafka client id and client secret?
A: No, the username and password for accessing and logging into the Destination Controller UI is different from the client ID and client secret required for the Kafka API.
Q: Will the IP address ranges sent for whitelisting also be whitelisted for Destination Controller UI?
A: Yes
Q: Can we choose to have different IP Addresses whitelisted for the UI vs Kafka API?
A: We can’t whitelist different IP ranges for DCs and kafka topics although this is something we are looking to add in the future. We currently whitelist IPs for accessing both.
Q: What values should we use for consumerGroupId and topic to connect to the Kafka API?
A: The topic name is not linked to the consumer group id, we provide the topic name: "openbet.cfs.output.”Operator Name". We ask that you prefix your consumer group id with your operator name_" (e.g., operator name_123) and consume from the topic provided.
Q: What settings are needed to connect to the Kafka API?
A: Certain settings are necessary to establish a connection. These include bootstrapServers, consumerGroupId, tokenEndpoint, jwksEndpoint, clientId, clientSecret, and topic.
Q: What happens if the client secret is invalid?
A: If the client secret is invalid, an error message stating "unauthorized_client" will be received. A valid client secret is needed for successful authentication.
Q: We are seeing multiple heartbeats at around the same time, is this correct?
A: There are multiple DC’s running in the environment which each produce a heartbeat. As long as you receive at least one heartbeat every 5 seconds you do not need to worry about which DC instance has sent it
Last updated